Authentication method and authentication system

BACKGROUND

00011. Technical Field

0002The present disclosure relates to a technique for authenticating a device connected to an area network and relates specifically to a technique for performing mutual authentication between a controller and a device and updating a group key.

00032. Description of the Related Art

0004Currently, services that utilize various types of history information collected by a cloud server from home electrical appliances, AV devices, household equipment, and other devices having a network connection function (hereinafter simply referred to as “devices”) are anticipated. A network formed by connecting devices installed in a home with one another is hereinafter referred to as a home area network.

0005In some cases, a specific device (hereinafter referred to as “controller”) is connected to the home area network, and communication between the devices and an external server is performed via the controller. In such cases, it is necessary to control communication in the home by securely making connections between the controller and the devices and to prevent connections from being made by an unauthorized device conducting spoofing activity or information from leaking out by interception of the content of communication, for example. Countermeasures, such as authentication of a device to be connected, can be taken against the former case, and countermeasures, such as encryption of communication, can be taken against the latter case, for example. The controller and a device whose validity has been confirmed share an encryption key and perform encrypted communication with each other using the encryption key. In a case where there are a plurality of devices that are to be connected to the controller, the controller and the devices share the same encryption key (hereinafter referred to as “group key”) to thereby enable encryption of multicast communication or broadcast communication in which the controller simultaneously transmits the same information to the plurality of devices.

0006In existing authentication systems as described above, group keys need to be further improved.

SUMMARY

0007In one general aspect, the techniques disclosed here feature an authentication method performed in an authentication system including a controller, a first device, and a second device. The authentication method includes: a first step comprising: performing mutual authentication between the controller and the first device, creating a group key, sharing the group key between the controller and the first device, and setting the first device as a reference device; a second step comprising: performing mutual authentication between the controller and the second device, and sharing the group key with the second device; a third step performed after the second step comprising: performing mutual authentication between the controller and the first device, updating the group key, and sharing the updated group key between the controller and the first device; and a fourth step performed at a group key update timing when the group key is updated comprising: performing mutual authentication between the controller and the second device, and sharing the updated group key with the second device.

0008According to the present disclosure, group keys used in authentication systems can be further improved.

0009It should be noted that general or specific embodiments may be implemented as a system, a method, an integrated circuit, a computer program, a storage medium, or any selective combination thereof.

0010Additional benefits and advantages of the disclosed embodiments will become apparent from the specification and drawings. The benefits and/or advantages may be individually obtained by the various embodiments and features of the specification and drawings, which need not all be provided in order to obtain one or more of such benefits and/or advantages.

BRIEF DESCRIPTION OF THE DRAWINGS

0011<figref idref="DRAWINGS">FIG. 1</figref> is a schematic diagram illustrating a system configuration of an authentication system;

0012<figref idref="DRAWINGS">FIG. 2</figref> is a functional block diagram of principal part of a controller;

0013<figref idref="DRAWINGS">FIG. 3</figref> is a diagram illustrating an example of a data structure and data of a connecting device management table;

0014<figref idref="DRAWINGS">FIG. 4</figref> is a diagram illustrating an example of a data structure of a public key certificate;

0015<figref idref="DRAWINGS">FIG. 5</figref> is a diagram illustrating an example of a data structure of a CRL;

0016<figref idref="DRAWINGS">FIG. 6</figref> is a functional block diagram of principal part of a device;

0017<figref idref="DRAWINGS">FIG. 7</figref> is a diagram illustrating an example of a data structure and data of a connecting controller management table;

0018<figref idref="DRAWINGS">FIG. 8</figref> is a functional block diagram of principal part of a server;

0019<figref idref="DRAWINGS">FIG. 9</figref> is a diagram illustrating an example of a data structure and data of a device information management table;

0020<figref idref="DRAWINGS">FIG. 10</figref> is a flowchart illustrating an example of a procedure of a device registration process performed by the device;

0021<figref idref="DRAWINGS">FIG. 11</figref> is a flowchart illustrating an example of a procedure of a device registration process performed by the controller;

0022<figref idref="DRAWINGS">FIG. 12</figref> is a sequence chart illustrating an example of a procedure of a device registration process;

0023<figref idref="DRAWINGS">FIG. 13</figref> is a flowchart illustrating an example of a procedure of a session update process performed by the device;

0024<figref idref="DRAWINGS">FIG. 14</figref> is a flowchart illustrating an example of a procedure of a session update process performed by the controller;

0025<figref idref="DRAWINGS">FIG. 15</figref> is a sequence chart illustrating an example of a procedure of a session update process;

0026<figref idref="DRAWINGS">FIG. 16</figref> is a flowchart illustrating an example of a procedure from PKI-based mutual authentication to shared key creation performed by the device;

0027<figref idref="DRAWINGS">FIG. 17</figref> is a flowchart illustrating an example of a procedure from PKI-based mutual authentication to shared key creation performed by the controller;

0028<figref idref="DRAWINGS">FIG. 18</figref> is a sequence chart illustrating an example of a procedure from PKI-based mutual authentication to shared key creation;

0029<figref idref="DRAWINGS">FIG. 19</figref> is a flowchart illustrating an example of a procedure from shared-key-using mutual authentication to session-related information creation performed by the device;

0030<figref idref="DRAWINGS">FIG. 20</figref> is a flowchart illustrating an example of a procedure from shared-key-using mutual authentication to session-related information creation performed by the controller;

0031<figref idref="DRAWINGS">FIG. 21</figref> is a sequence chart illustrating an example of a procedure from shared-key-using mutual authentication to session-related information creation;

0032<figref idref="DRAWINGS">FIG. 22</figref> is a sequence chart illustrating an example of a procedure of a device history information transmission process;

0033<figref idref="DRAWINGS">FIG. 23</figref> is a sequence chart illustrating an example of a procedure of a control information transmission process;

0034<figref idref="DRAWINGS">FIG. 24</figref> is a diagram illustrating an example of a data structure and data of a connecting device management table according to a second embodiment;

0035<figref idref="DRAWINGS">FIG. 25</figref> is a flowchart illustrating an example of a procedure of a session update process performed by the device according to the second embodiment;

0036<figref idref="DRAWINGS">FIG. 26</figref> is a flowchart illustrating an example of a procedure of a session update process performed by the controller according to the second embodiment;

0037<figref idref="DRAWINGS">FIG. 27</figref> is a sequence chart illustrating an example of a procedure of a session update process according to the second embodiment;

0038<figref idref="DRAWINGS">FIG. 28</figref> is a diagram illustrating an example of a data structure and data of a connecting device management table according to a third embodiment;

0039<figref idref="DRAWINGS">FIG. 29</figref> is a diagram illustrating an example of a data structure and data of a connecting controller management table according to the third embodiment;

0040<figref idref="DRAWINGS">FIG. 30</figref> is a flowchart illustrating an example of a procedure of a session update process performed by the device according to the third embodiment;

0041<figref idref="DRAWINGS">FIG. 31</figref> is a flowchart illustrating an example of a procedure of a session update process performed by the controller according to the third embodiment; and

0042<figref idref="DRAWINGS">FIG. 32</figref> is a sequence chart illustrating an example of a procedure of a session update process according to the third embodiment.

DETAILED DESCRIPTION

Underlying Knowledge Forming Basis of the Present Disclosure

0043In order to maintain security between devices and a controller, it is desired that the devices and the controller do not continue using the same group keys after mutual authentication performed upon connection and that the devices and the controller update the group keys.

0044However, if the devices update their group keys at respective timings, the devices respectively retain different group keys. For example, in a case where a first device retains a group key after an update but a second device retains a group key before an update, the controller is unable to simultaneously transmit (perform broadcast transmission) encrypted information to the devices using a group key.

0045The present disclosure has been made in view of the above-described issue and provides an authentication method with which devices and a controller can update their group keys at the same timing.

0046In the authentication method according to an aspect of the present disclosure, a device among the devices connected to the controller is set as a reference device, and devices other than the reference device update their group keys on the basis of a group key update timing of the reference device to thereby enable the plurality of devices to update their group keys at the same timing.

0047Accordingly, even if the controller and the devices perform mutual authentication and a group key update, the controller can simultaneously transmit encrypted information to the devices.

0048Hereinafter, embodiments of the present disclosure will be described with reference to the drawings. Note that the following embodiments are merely operative examples of the present disclosure and are not intended to limit the technical scope of the present disclosure.

1. First Embodiment

1-1. Overview

0049Hereinafter, an authentication system <b>10</b> using the authentication method according to the present disclosure will be described as one embodiment with reference to the drawings.

0050<figref idref="DRAWINGS">FIG. 1</figref> is a schematic diagram illustrating an example of a system configuration of the authentication system <b>10</b> according to this embodiment.

0051The authentication system <b>10</b> includes a controller <b>100</b>, a device <b>200</b><i>a</i>, a device <b>200</b><i>b</i>, and a device <b>200</b><i>c </i>that are connected to a home area network <b>400</b>. The controller <b>100</b> in the authentication system <b>10</b> is connected to a server <b>300</b> over a network <b>500</b>, which is a communication network, such as the Internet.

0052The controller <b>100</b> and the devices <b>200</b><i>a </i>to <b>200</b><i>c </i>are connected to one home area network <b>400</b> and may be connected to the home area network <b>400</b> via a network device (hub, router, or the like, for example), which is not illustrated. The controller <b>100</b> or the devices may be installed indoors or outdoors.

0053The controller <b>100</b> and each of the devices <b>200</b><i>a </i>to <b>200</b><i>c </i>perform mutual authentication when making a connection. In a case where their validity has been mutually confirmed as a result of mutual authentication, the controller and each of the devices <b>200</b><i>a </i>to <b>200</b><i>c </i>share an encryption key and perform encrypted communication. The controller and the respective devices thereafter perform a session update process at their predetermined respective timings, perform mutual authentication each time the session update process is performed, update their encryption keys if the result of mutual authentication shows that they are valid, and continue performing encrypted communication.

0054The controller <b>100</b> and each device share three types of shared keys after mutually confirming their validity in mutual authentication upon making a connection.

0055A first shared key is a shared key used by the controller <b>100</b> and each device in mutual authentication upon session update processing. When the controller and each device are to be connected to each other, the controller and the device first perform mutual authentication based on a public key infrastructure (PKI). The method for mutual authentication based on a PKI uses a general technique described in Atsuko Miyaji/Hiroaki Kikuchi, “IT Text Information Security”, Ohmsha, Ltd., October 2003 and the like, and therefore, description thereof will be omitted. After the mutual authentication based on a PKI, mutual authentication upon session update processing is performed by the controller and the device using the first shared key. Hereinafter, “shared key” simply mentioned refers to the shared key used in the mutual authentication except for a case where the shared key obviously refers to a group key or a session key described below.

0056In encrypted communication between the controller and a device, a shared key encryption scheme is used, and therefore, the controller and the device share the shared key.

0057A second shared key and a third shared key are shared keys used in the encrypted communication and are respectively referred to as a group key and a session key. The group key is an encryption key used by the controller for simultaneously transmitting the same information to a plurality of devices, and the controller shares the same group key with all devices connected to the controller. The session key is an encryption key used by the controller and each device for performing one-to-one unicast communication, and the controller shares an individual encryption key with each device.

0058Here, it is assumed that a session validity period is set for communication between the controller and each device and that the group key and the session key are usable in the session validity period. In a case where the session validity period has elapsed after session establishment, control is performed so that the group key and the session key are no longer usable. In order to continue performing encrypted communication even after the session validity period has elapsed, the controller and each device need to perform a session update process, create a new group key and session key, and establish a new session.

0059The controller sets one of a plurality of devices that are connected to the controller as a reference device. The timings when the controller <b>100</b> and the devices respectively update their group keys is based on the timing when the reference device performs a session update process and updates its group key, and the method will be specifically described below. Note that the reference device is a device that is connected to the controller <b>100</b> first.

0060The server <b>300</b> is an external server that provides services and the like to the devices <b>200</b><i>a </i>to <b>200</b><i>c</i>. Communication between the server <b>300</b> and each device is performed via the controller <b>100</b>.

0061For example, each device transmits device history information indicating operations of the device to the server <b>300</b> via the controller <b>100</b>. The server <b>300</b> transmits service information to each device via the controller <b>100</b>. Here, it is assumed that the server <b>300</b> transmits control request information for making each device execute a predetermined function. The controller <b>100</b> receives and interprets the control request information, and creates and transmits a control command for making each device execute the function. Each device that receives the control command executes the function requested by the server <b>300</b>.

1-2. Configurations

0062The configurations of the controller <b>100</b> and the devices <b>200</b><i>a </i>to <b>200</b><i>c</i>, which are major constituent elements of the authentication system <b>10</b> according to this embodiment, and the configuration of the server <b>300</b> connected to the authentication system <b>10</b> will be described with reference to the drawings.

1-2-1. Controller

100

0063<figref idref="DRAWINGS">FIG. 2</figref> is a functional block diagram of principal part of the controller <b>100</b>. The controller <b>100</b> includes a device management unit <b>101</b>, a device information storage unit <b>102</b>, an authentication processing unit <b>103</b>, an authentication information storage unit <b>104</b>, and a communication unit <b>105</b>. The controller <b>100</b> includes a processor and a memory, which are not illustrated, and the functions of the device management unit <b>101</b>, the device information storage unit <b>102</b>, the authentication processing unit <b>103</b>, the authentication information storage unit <b>104</b>, and the communication unit <b>105</b> are implemented by the processor executing a program stored in the memory. Storage of data by the device information storage unit <b>102</b> and the authentication information storage unit <b>104</b> is implemented by using the memory.

Device Management Unit

101

0064The device management unit <b>101</b> has the following functions in order to control connections between the controller <b>100</b> and the devices <b>200</b><i>a </i>to <b>200</b><i>c. </i>

0065The device management unit <b>101</b> accepts via the communication unit <b>105</b> a connection request and a session update request made by a device to the controller <b>100</b> and makes the authentication processing unit <b>103</b> perform a mutual authentication process for the device.

0066In a case where the validity of the device is confirmed as a result of the authentication process performed by the authentication processing unit <b>103</b>, the device management unit <b>101</b> registers connecting device management data in a connecting device management table <b>1000</b> stored in the device information storage unit <b>102</b>. The connecting device management data stored in the connecting device management table <b>1000</b> will be described in detail below.

0067The device management unit <b>101</b> sets the reference device. For example, the device management unit <b>101</b> may set a device that is connected to the controller <b>100</b> first as the reference device. In a case where a connection with a device that is registered as the reference device is lost, the device management unit <b>101</b> extracts another device from the connecting device management table <b>1000</b> stored in the device information storage unit <b>102</b> and sets the device as the reference device. At this time, the device management unit <b>101</b> may set a device that is always turned on as the reference device. The device management unit <b>101</b> also registers the reference device having been set in the connecting device management table <b>1000</b>. Upon making a connection with a device, the authentication processing unit <b>103</b> determines whether the device is set as the reference device, and the device management unit <b>101</b> registers the device in the connecting device management table <b>1000</b> in accordance with the result of determination.

0068The device management unit <b>101</b> refers to a session update state, which is an item of the connecting device management table <b>1000</b>, and sends via the communication unit <b>105</b> a session update notification to a device that has not performed a session update. The session update notification is a notification for urging the device to update its session. The session is updated when a session update request made by the device to the controller <b>100</b> is newly accepted thereafter.

0069The device management unit <b>101</b> refers to a remaining session time, which is an item of the connecting device management table <b>1000</b>, and disables encrypted communication with a device for which the session validity period has elapsed without performing a session update, that is, a device for which the remaining session time is zero, by deleting information about encryption keys, such as a group key and a session key, retained for the device.

0070The device management unit <b>101</b> decrypts encrypted device history information received from the devices <b>200</b><i>a </i>to <b>200</b><i>c </i>via the communication unit <b>105</b>. The device management unit <b>101</b> transmits the decrypted device history information to the server <b>300</b> via the communication unit <b>105</b>.

0071The device management unit <b>101</b> converts control request information for a device received from the server <b>300</b> via the communication unit <b>105</b> into a format with which an instruction can be given to the device, encrypts the control request information using the group key or the session key, and transmits the control request information to the device via the communication unit <b>105</b>.

Device Information Storage Unit

102

0072The device information storage unit <b>102</b> stores information about the devices <b>200</b><i>a </i>to <b>200</b><i>c </i>connected to the controller <b>100</b>. <figref idref="DRAWINGS">FIG. 3</figref> is a diagram illustrating an example of a data structure and data of the connecting device management table <b>1000</b> stored in the device information storage unit <b>102</b> for managing information about the devices.

0073The connecting device management table <b>1000</b> is constituted by a group of connecting device management records for respective devices. The connecting device management record is data that is registered in a case where a device is recognized as a valid device in a device registration process that is performed when a connection is made between the device and the controller, and includes items, namely, a device ID <b>1010</b>, a certificate ID <b>1020</b>, a shared key <b>1030</b>, a group key <b>1040</b>, a session key <b>1050</b>, a remaining session time <b>1060</b>, a session update state <b>1070</b>, and a reference device <b>1080</b>.

0074Each item is described with reference to the example of data in <figref idref="DRAWINGS">FIG. 3</figref>.

0075The device ID <b>1010</b> is an identifier for uniquely identifying the device.

0076The certificate ID <b>1020</b> is the certificate ID of the public key certificate of the device.

0077The shared key <b>1030</b> is data about a shared key that is shared between the controller <b>100</b> and the device.

0078The group key <b>1040</b> is data about a group key used to encrypt information that is simultaneously transmitted by the controller <b>100</b> to a plurality of devices. <figref idref="DRAWINGS">FIG. 3</figref> indicates that the same group key “11223 . . . ” is shared with all of the devices ID<b>1</b> to ID<b>3</b> that are connected to the controller. In <figref idref="DRAWINGS">FIG. 3</figref>, although the example is illustrated where the devices ID<b>1</b> to ID<b>3</b> share one column of the group key item, individual item columns may be provided for the respective device IDs, and data about the same group key as that of the reference device may be set for devices other than the reference device upon registration of the item.

0079The session key <b>1050</b> is data about a session key used to encrypt unicast communication between the controller <b>100</b> and the device. The example in <figref idref="DRAWINGS">FIG. 3</figref> indicates that the controller <b>100</b> shares different session keys with the respective devices ID<b>1</b> to ID<b>3</b>.

0080The remaining session time <b>1060</b> is a remaining period of a session validity period that is set by the controller <b>100</b> and the device. A specific session validity period that is determined in advance is set for the controller <b>100</b> and the device. The session validity period is registered as the remaining session time <b>1060</b> each time a session is established or updated. Thereafter, the value of the item counts down as time passes, so that the remaining session time <b>1060</b> indicates the remaining period of the session validity period.

0081For a device for which the remaining session time becomes zero, the device management unit <b>101</b> deletes information about the group key and the session key that are retained for the device to thereby disable encrypted communication.

0082The session update state <b>1070</b> is data indicating whether the device indicated by the device ID has performed a session update with the controller <b>100</b> in a period after the controller <b>100</b> and the reference device have performed a session update. At the time when the controller <b>100</b> performs a session update with the reference device, the session update state <b>1070</b> of any device other than the reference device is updated to “not updated”. Thereafter, at the time when the controller <b>100</b> performed a session update process for the device, the session update state <b>1070</b> is updated to “updated”.

0083The item of the reference device <b>1080</b> is data indicating whether the device is the reference device.

0084The items of the session update state <b>1070</b> and the reference device <b>1080</b> in the example in <figref idref="DRAWINGS">FIG. 3</figref> indicate that the device having device ID<b>1</b> is the reference device and that the controller has already performed a session update with the device having device ID<b>2</b> but has not performed a session update with the device having device ID<b>3</b> after the controller <b>100</b> and the device having device ID<b>1</b>, which is the reference device, have performed a session update.

Authentication Processing Unit

103

0085The authentication processing unit <b>103</b> has a function of performing a mutual authentication process with a device that is connected to the controller <b>100</b>. Upon making a connection with a device, the authentication processing unit <b>103</b> performs mutual authentication based on a PKI. Upon a session update, the authentication processing unit <b>103</b> performs mutual authentication based on challenge-response authentication that uses a shared key and random numbers.

0086The authentication processing unit <b>103</b> accepts from the device management unit <b>101</b> a request for authentication of a device and the public key certificate of the device and performs an authentication process based on a PKI. Specifically, the authentication processing unit <b>103</b> first confirms, on the basis of a CRL (Certificate Revocation List) stored in the authentication information storage unit <b>104</b>, that the certificate ID of the obtained public key certificate of the device is not included in the CRL. The authentication processing unit <b>103</b> verifies a signature added to the public key certificate by using the public key of a certifying authority. Here, it is assumed that the certifying authority is the server <b>300</b>.

0087The authentication processing unit <b>103</b> performs challenge-response authentication, which is mutual authentication using a shared key, upon a session update between the controller <b>100</b> and a device. The authentication processing unit <b>103</b> also has a function of creating the shared key through a key exchange with the device. The authentication processing unit <b>103</b> generates random numbers and transmits the random numbers to the device via the communication unit <b>105</b>. The authentication processing unit <b>103</b> decrypts random numbers that the device has encrypted using its shared key and has returned by using the shared key retained by the controller and checks the result against the random numbers that the authentication processing unit <b>103</b> has created to thereby confirm the validity of the device. Similarly, the authentication processing unit <b>103</b> encrypts the random numbers received from the device by using its shared key and returns the result, and the device performs verification.

0088The authentication processing unit <b>103</b> further has a function of performing processes necessary for establishing and updating a session. Specifically, the authentication processing unit <b>103</b> creates a group key and a session key, which are shared keys for encrypting communication between the controller <b>100</b> and a device. The authentication processing unit <b>103</b> also sets the session validity period and registers the session validity period in the connecting device management table <b>1000</b> stored in the device information storage unit <b>102</b> via the device management unit <b>101</b> together with the session key and the group key.

Authentication Information Storage Unit

104

0089The authentication information storage unit <b>104</b> stores the private key and the public key certificate of the controller <b>100</b>. The authentication information storage unit <b>104</b> also stores the CRL used in mutual authentication based on a PKI to confirm that the public key certificate of a counterpart device has not expired. The private key, the public key certificate, and the CRL are embedded in the controller <b>100</b> upon manufacturing of the controller <b>100</b>.

0090<figref idref="DRAWINGS">FIG. 4</figref> is a diagram illustrating a data structure of a public key certificate <b>1500</b>, which is an example of a standard data structure of a public key certificate. The public key certificate <b>1500</b> includes a version <b>1510</b>, an issuer <b>1520</b>, the beginning of the validity period <b>1530</b>, the end of the validity period <b>1540</b>, a certificate ID <b>1550</b>, a public key <b>1560</b>, and a signature <b>1570</b> of the server <b>300</b>, which is the certifying authority, related to the certificate. Here, the public key <b>1560</b> is data about the public key of the controller, and the signature <b>1570</b> is a signature created by using the private key of the certifying authority and added.

0091<figref idref="DRAWINGS">FIG. 5</figref> is a diagram illustrating a CRL <b>1600</b>, which is an example of a standard data structure of a CRL. The CRL <b>1600</b> includes a CRL version <b>1610</b>, an issuer <b>1620</b>, an issue date <b>1630</b>, a next issue date <b>1640</b>, an expired certificate ID <b>1650</b>, and a signature <b>1660</b> of the server, which is the certifying authority, related to the CRL. Here, only one ID need not be included in the expired certificate ID <b>1650</b>, and IDs of a plurality of expired certificates may be included. Further, the signature <b>1660</b> is a signature created by using the private key of the certifying authority and added.

Communication Unit

105

0092The communication unit <b>105</b> is a communication interface for the controller <b>100</b> to make a connection to each of the devices <b>200</b><i>a </i>to <b>200</b><i>c </i>and the server <b>300</b>. For example, the communication unit <b>105</b> has a function of performing encrypted communication with the devices <b>200</b><i>a </i>to <b>200</b><i>c </i>by using the session keys and the group key stored in the connecting device management table <b>1000</b> of the device information storage unit <b>102</b>.

0093The communication unit <b>105</b> further has a function of performing encrypted communication with the server <b>300</b> and performs SSL (Secure Socket Layer) communication, for example. Here, an SSL server certificate necessary for SSL communication is retained by the communication unit <b>105</b>.

1-2-2. Device

200

a

0094The devices <b>200</b><i>a </i>to <b>200</b><i>c </i>are home electrical appliances, AV devices, or household equipment having a function of connecting to a network and are specifically televisions, recorders, air conditioners, refrigerators, storage batteries, or the like, for example.

0095Hereinafter, the configurations of the devices, typically, the configuration of the device <b>200</b><i>a</i>, will be described. Note that the devices respectively have functions specific thereto, and therefore, a device of a different type is not the same as other devices in this regard. For example, a specific function is a washing function of a washing machine or heating and cooling functions of an air conditioner, for example. These functions are general functions, and therefore, description thereof will be omitted. Only functions related to the authentication method, which is the present disclosure, will be described. Regarding these functions, other devices as well as the device <b>200</b><i>a </i>have the same functions as a matter of course.

0096<figref idref="DRAWINGS">FIG. 6</figref> is a functional block diagram of principal part of the device <b>200</b><i>a</i>. The device <b>200</b><i>a </i>includes a device management unit <b>201</b>, a device history storage unit <b>202</b>, a device information storage unit <b>203</b>, an authentication processing unit <b>204</b>, an authentication information storage unit <b>205</b>, and a communication unit <b>206</b>. The device <b>200</b><i>a </i>includes a processor and a memory, which are not illustrated, and the functions of the device management unit <b>201</b>, the device history storage unit <b>202</b>, the device information storage unit <b>203</b>, the authentication processing unit <b>204</b>, the authentication information storage unit <b>205</b>, and the communication unit <b>206</b> are implemented by the processor executing a program stored in the memory. Storage of data by the device history storage unit <b>202</b>, the device information storage unit <b>203</b>, and the authentication information storage unit <b>205</b> is implemented by using the memory.

Device Management Unit

201

0097The device management unit <b>201</b> controls a connection with the controller <b>100</b>. Specifically, the device management unit <b>201</b> has the following functions.

0098The device management unit <b>201</b> transmits a connection request to the controller <b>100</b> via the communication unit <b>206</b> upon making a connection with the controller <b>100</b>.

0099When the device management unit <b>201</b> receives the public key certificate of the controller <b>100</b> via the communication unit <b>206</b>, the device management unit <b>201</b> makes the authentication processing unit <b>204</b> perform an authentication process based on a PKI.

0100In a case where the validity of the controller <b>100</b> is confirmed as a result of the authentication process performed by the authentication processing unit <b>204</b>, the device management unit <b>201</b> registers connecting controller data in a connecting controller management table <b>1100</b> stored in the device information storage unit <b>203</b>. The connecting controller data stored in the connecting controller management table <b>1100</b> will be described in detail below.

0101The device management unit <b>201</b> encrypts device history information about an operation history of the device recorded to the device history storage unit <b>202</b> by using the session key and transmits the result to the controller <b>100</b> via the communication unit <b>206</b>. The device history information about operations of the device is transmitted to the server <b>300</b> via the controller <b>100</b> at regular or irregular intervals.

0102The device management unit <b>201</b> refers to an item of a remaining session time stored in the connecting controller management table of the device information storage unit <b>203</b> and starts a session update at the time when the value of the remaining session time decreases to a specific threshold determined in advance or below. The specific threshold is set to a value equal to 10% of the session validity period or a value equal to twice the time necessary for a session update process, for example. However, when the device management unit <b>201</b> receives a session update notification from the controller <b>100</b>, the device management unit <b>201</b> starts a session update regardless of the value of the remaining session time.

0103When the device management unit <b>201</b> starts a session update, the device management unit <b>201</b> makes the authentication processing unit <b>204</b> perform processing. Thereafter, the device management unit <b>201</b> receives a group key, a session key, and a session validity period created by the authentication processing unit <b>204</b> and registers the group key, the session key, and the session validity period in the connecting controller management table <b>1100</b> stored in the device information storage unit <b>203</b>.

Device History Storage Unit

202

0104The device history storage unit <b>202</b> has a function of recording operations of the device <b>200</b><i>a </i>as device history information and storing the information. Each time the device <b>200</b><i>a </i>is operated or executes a function, the device history storage unit <b>202</b> records information indicating the operation as device history information. Although the device history information is mentioned as an example of information that the device <b>200</b><i>a </i>transmits to the server <b>300</b> via the controller <b>100</b>, the device history information is not a principal constituent element of the present disclosure. Therefore, detailed description of the data items and the like will be omitted.

Device Information Storage Unit

203

0105The device information storage unit <b>203</b> stores information about the controller <b>100</b> that is connected to the device <b>200</b><i>a</i>. <figref idref="DRAWINGS">FIG. 7</figref> is a diagram illustrating an example of a data structure and data of the connecting controller management table <b>1100</b> that is stored in the device information storage unit <b>203</b> for managing information about the controller.

0106The connecting controller management table <b>1100</b> is constituted by a group of connecting controller management records. The connecting controller management record is data that is registered in a case where a controller is recognized as a valid device in a device registration process that is performed when a connection is made between the device and the controller, and includes items, namely, a controller ID <b>1110</b>, a certificate ID <b>1120</b>, a shared key <b>1130</b>, a group key <b>1140</b>, a session key <b>1150</b>, and a remaining session time <b>1160</b>.

0107Each item is described with reference to the example in <figref idref="DRAWINGS">FIG. 7</figref>.

0108The controller ID <b>1110</b> is an identifier for uniquely identifying the controller.

0109The certificate ID <b>1120</b> is the certificate ID of the public key certificate of the controller.

0110The shared key <b>1130</b> is data about a shared key that the device <b>200</b><i>a </i>shares with the controller <b>100</b>.

0111The group key <b>1140</b> is data about a shared key used to encrypt information that is simultaneously transmitted by the controller <b>100</b> to devices. The devices decrypt the received information by using the group key.

0112The session key <b>1150</b> is data about a shared key used to perform encrypted unicast communication with the controller <b>100</b>.

0113The remaining session time <b>1160</b> is a remaining period of a session validity period that is set with the controller <b>100</b>. A specific session validity period that is determined in advance is set for the device <b>200</b><i>a </i>and the controller <b>100</b>. The session validity period is registered as the remaining session time <b>1160</b> each time a session is established or updated. Thereafter, the value of the item counts down as time passes, so that the remaining session time <b>1160</b> indicates the remaining period of the session validity period.

Authentication Processing Unit

204

0114The authentication processing unit <b>204</b> has a function of performing a mutual authentication process with the controller <b>100</b>. Upon making a connection with the controller, the authentication processing unit <b>204</b> performs mutual authentication based on a PKI. Upon a session update, the authentication processing unit <b>204</b> performs mutual authentication based on challenge-response authentication that uses a shared key and random numbers.

0115The authentication processing unit <b>204</b> accepts from the device management unit <b>201</b> a request for authentication of a controller and the public key certificate of the controller and performs an authentication process based on a PKI. Specifically, the authentication processing unit <b>204</b> confirms, on the basis of a CRL stored in the authentication information storage unit <b>205</b>, that the certificate ID of the obtained public key certificate of the controller is not included in the CRL. The authentication processing unit <b>204</b> verifies a signature added to the public key certificate by using the public key of a certifying authority. Here, it is assumed that the certifying authority is the server <b>300</b>.

0116The authentication processing unit <b>204</b> performs challenge-response authentication, which is mutual authentication using a shared key, with the controller <b>100</b> upon a session update. The authentication processing unit <b>204</b> also has a function of creating the shared key through a key exchange with the controller <b>100</b>. The authentication processing unit <b>204</b> generates random numbers and transmits the random numbers to the controller <b>100</b> via the communication unit <b>206</b>. The authentication processing unit <b>204</b> decrypts random numbers that the controller <b>100</b> has encrypted using its shared key and has returned by using the shared key retained by the device and checks the result against the random numbers that the authentication processing unit <b>204</b> has created to thereby confirm the validity of the controller. Similarly, the authentication processing unit <b>204</b> encrypts the random numbers received from the controller by using its shared key and returns the result, and the controller performs verification.

0117The authentication processing unit <b>204</b> further has a function of performing processes necessary for creating and updating a session. Specifically, when the authentication processing unit <b>204</b> accepts an instruction for starting a session update process from the device management unit <b>201</b>, the authentication processing unit <b>204</b> transmits a session update request to the controller <b>100</b> via the communication unit <b>206</b>. The authentication processing unit <b>204</b> receives a session key, a group key, and a session validity period after the update from the controller <b>100</b> via the communication unit <b>206</b> and registers the session key, the group key, and the session validity period in the connecting controller management table <b>1100</b> stored in the device information storage unit <b>203</b> via the device management unit <b>201</b>.

Authentication Information Storage Unit

205

0118The authentication information storage unit <b>205</b> stores the private key and the public key certificate of the device <b>200</b><i>a</i>. The authentication information storage unit <b>205</b> also stores the CRL used in mutual authentication based on a PKI to confirm that a public key certificate has not expired. The private key, the public key certificate, and the CRL are embedded in the device upon manufacturing of the device.

0119The data structures of the CRL and the public key certificate are similar to those stored in the authentication information storage unit <b>104</b> of the controller <b>100</b>, and therefore, description thereof will be omitted. As a matter of course, the public key included in the public key certificate of the device <b>200</b><i>a </i>is the public key of the device <b>200</b><i>a. </i>

Communication Unit

206

0120The communication unit <b>206</b> is a communication interface for making a connection to the controller <b>100</b>. For example, the communication unit <b>206</b> has a function of performing encrypted communication with the controller <b>100</b> by using the session key and the group key stored in the connecting controller management table <b>1100</b> of the device information storage unit <b>203</b>.

1-2-3. Server

300

0121<figref idref="DRAWINGS">FIG. 8</figref> is a functional block diagram of principal part of the server <b>300</b>. The server <b>300</b> includes a device information management unit <b>301</b>, a device information storage unit <b>302</b>, a CRL management unit <b>303</b>, a CRL storage unit <b>304</b>, and a communication unit <b>305</b>. The server <b>300</b> includes a processor and a memory, which are not illustrated, and the functions of the device information management unit <b>301</b>, the device information storage unit <b>302</b>, the CRL management unit <b>303</b>, the CRL storage unit <b>304</b>, and the communication unit <b>305</b> are implemented by the processor executing a program stored in the memory. Storage of data by the device information storage unit <b>302</b> and the CRL storage unit <b>304</b> is implemented by using the memory.

Device Information Management Unit

301

0122The device information management unit <b>301</b> has the following functions for controlling the device information storage unit <b>302</b> and managing information about a controller that is connected to the server <b>300</b> and information about devices that are connected to the controller.

0123The device information management unit <b>301</b> registers information about the controller and devices received from the controller via the communication unit <b>305</b> in a device information management table <b>1300</b> stored in the device information storage unit <b>302</b>.

0124In a case where the device information management unit <b>301</b> receives, from the controller, information about a device that is determined to be invalid in mutual authentication between the controller and the device, the device information management unit <b>301</b> communicates the certificate ID of the public key certificate of the device to the CRL management unit <b>303</b>.

Device Information Storage Unit

302

0125The device information storage unit <b>302</b> stores information about a controller that is connected to the server <b>300</b> and about devices. <figref idref="DRAWINGS">FIG. 9</figref> is a diagram illustrating an example of a data structure and data of the device information management table <b>1300</b> included in the device information storage unit <b>302</b>.

0126The device information management table <b>1300</b> includes items related to the controller, namely, a controller ID <b>1310</b> and a certificate ID <b>1320</b>. The device information management table <b>1300</b> further includes items related to a device that is connected to the controller, namely, a device ID <b>1330</b>, a certificate ID <b>1340</b>, and device history information <b>1350</b>. Each item is described with reference to the example in <figref idref="DRAWINGS">FIG. 9</figref>.

0127The controller ID <b>1310</b> is an identifier for uniquely identifying the controller.

0128The controller certificate ID <b>1320</b> is the certificate ID of the public key certificate of the controller.

0129The device ID <b>1330</b> is a device ID for identifying a device that is connected to the controller. The example in <figref idref="DRAWINGS">FIG. 9</figref> indicates that three devices identified by using device ID<b>1</b>, device ID<b>2</b>, and device ID<b>3</b> are connected to the controller that is identified by using controller ID<b>1</b>.

0130The device certificate ID <b>1340</b> is the certificate ID of the public key certificate of the device.

0131The device history information <b>1350</b> is data about device history information collected from a device. Here, the device history information itself may be stored in a separate table for each device, and information about a link to the separate table may be included in the item of the device history information <b>1350</b>.

CRL Management Unit

303

0132When the CRL management unit <b>303</b> accepts the certificate ID of the public key certificate of an unauthorized device from the device information management unit <b>301</b>, the CRL management unit <b>303</b> issues a CRL.

0133The CRL management unit <b>303</b> retains the public key and the private key of the server <b>300</b>.

0134The CRL management unit <b>303</b> adds, upon issuance of a CRL, a signature created by using the private key of the server <b>300</b> to the CRL. A controller and a device that use the CRL verify the signature added to the CRL by using the public key of the server <b>300</b> to thereby confirm that the CRL is valid.

0135The CRL issued by the CRL management unit is transmitted to the controller and devices via the communication unit <b>305</b>.

CRL Storage Unit

304

0136The CRL storage unit <b>304</b> stores a CRL issued by the CRL management unit <b>303</b>. The data structure of the CRL is similar to that stored in the authentication information storage unit <b>104</b> of the controller <b>100</b>, and therefore, description thereof will be omitted.

Communication Unit

305

0137The communication unit <b>305</b> is a communication interface for communicating with the controller <b>100</b>. Communication between the server <b>300</b> and the controller <b>100</b> is performed through SSL communication, for example. A certificate necessary for SSL communication is retained by the communication unit <b>305</b>.

1-3. Operations

0138Hereinafter, “device registration process”, “session update process”, “PKI-based mutual authentication to shared key creation”, “shared-key-using mutual authentication to session-related information creation”, “device history information transmission process”, and “control information transmission process” performed in the authentication system <b>10</b> will be described one by one. Note that “PKI-based mutual authentication to shared key creation”, which is a process performed in “device registration process”, and “shared-key-using mutual authentication to session-related information creation”, which is a process performed in “device registration process” and “session update process”, are illustrated as subroutines for convenience.

Device Registration Process

0139<figref idref="DRAWINGS">FIG. 10</figref> and <figref idref="DRAWINGS">FIG. 11</figref> are flowcharts illustrating examples of procedures of device registration processes respectively performed by a device and the controller. <figref idref="DRAWINGS">FIG. 12</figref> is a sequence chart illustrating an example of a procedure of the device registration process that includes interaction between a device and the controller.

0140The device registration process is a process that is performed when the controller <b>100</b> and a device are to be connected to each other and is a procedure in which the device makes a connection request to the controller <b>100</b>, and the device and the controller <b>100</b> register each other after mutual authentication. First, the processes respectively performed by a device and the controller are outlined with reference to the flowcharts in <figref idref="DRAWINGS">FIG. 10</figref> and <figref idref="DRAWINGS">FIG. 11</figref>. Then, a more detailed procedure of the device registration process including interaction between a device and the controller is described with reference to the sequence chart in <figref idref="DRAWINGS">FIG. 12</figref>.

0141The device registration process performed by a device is outlined with reference to the flowchart in <figref idref="DRAWINGS">FIG. 10</figref>.

0142First, a device transmits the device ID and the public key certificate thereof to the controller together with a connection request (step S<b>1010</b>).

0143Next, the device executes the subroutine “PKI-based mutual authentication to shared key creation” to thereby perform mutual authentication with the controller and thereafter share a shared key (step S<b>1020</b>). The subroutine process will be described in detail below.

0144If the return value from the subroutine in step S<b>1020</b> is “successful” (Yes in step S<b>1030</b>), the device executes the subroutine “shared-key-using mutual authentication to session-related information creation” to thereby perform mutual authentication with the controller using the shared key, thereafter create a group key and a session key, and set the session validity period, the group key, session key, and session validity period being session-related information (step S<b>1040</b>). The subroutine process will be described in detail below.

0145If the return value from the subroutine in step S<b>1040</b> is “successful” (Yes in step S<b>1050</b>), the device registers information about the controller as a valid connecting counterpart (step S<b>1060</b>).

0146On the other hand, if the return value from the subroutine in step s<b>1020</b> is “error” (No in step S<b>1030</b>) or if the return value from the subroutine in step S<b>1040</b> is “error” (No in step S<b>1050</b>), the device ends the device registration process.

0147Next, the device registration process performed by the controller is outlined with reference to the flowchart in <figref idref="DRAWINGS">FIG. 11</figref>.

0148The controller waits for a connection request from a device and the device ID and public key certificate of the device (step S<b>1110</b>). If these have not been received (No in step S<b>1110</b>), the controller continues waiting for a connection request from a device.

0149If a connection request has been received (Yes in step S<b>1110</b>), the controller performs the subroutine “PKI-based mutual authentication to shared key creation” to thereby perform mutual authentication with the device and thereafter share a shared key (step S<b>1120</b>). The subroutine process will be described in detail below.

0150If the return value from the subroutine in step S<b>1120</b> is “successful” (Yes in step S<b>1130</b>), the controller executes the subroutine “shared-key-using mutual authentication to session-related information creation” to thereby perform mutual authentication with the device using the shared key, thereafter create a group key and a session key, and set the session validity period, the group key, session key, and session validity period being session-related information (step S<b>1140</b>). The controller determines whether the device is set as the reference device (step S<b>1140</b>). The subroutine process will be described in detail below.

0151If the return value from the subroutine in step S<b>1140</b> is “successful” (Yes in step S<b>1150</b>), the controller transmits information about the controller and the device to the server <b>300</b> (step S<b>1160</b>).

0152The controller registers information about the device as a valid connecting counterpart (step S<b>1170</b>).

0153On the other hand, if the return value from the subroutine in step s<b>1120</b> is “error” (No in step S<b>1130</b>) or if the return value from the subroutine in step S<b>1140</b> is “error” (No in step S<b>1150</b>), the controller ends the device registration process.

0154Hereinafter, the details of the process including interaction between a device and the controller will be described with reference to the sequence chart in <figref idref="DRAWINGS">FIG. 12</figref>. Although description will be given while assuming the device <b>200</b><i>a </i>to be the device, for example, the process related to the device <b>200</b><i>b </i>and the device <b>200</b><i>c </i>is performed by following a procedure similar to that for the device <b>200</b><i>a </i>as a matter of course. The sequence chart illustrates a case where no error occurs, for example, and a process to be performed in a case where an error occurs will be described below.

0155The device registration process is a process to be performed when a new device is to be connected to the controller <b>100</b>. For example, the device registration process is performed at the time when a new device is added to a home area network to which the controller belongs or at the time when a device that is on the network and that has been turned off is turned on.

0156The device management unit <b>201</b> of the device <b>200</b><i>a </i>transmits a connection request to the controller <b>100</b> via the communication unit <b>206</b> (step S<b>101</b>). At this time, the device management unit <b>201</b> of the device <b>200</b><i>a </i>also transmits the device ID and the public key certificate of the device <b>200</b><i>a. </i>

0157The device management unit <b>101</b> of the controller <b>100</b> accepts the connection request via the communication unit <b>105</b> and makes the authentication processing unit <b>103</b> perform mutual authentication based on a PKI. In response to this, the authentication processing unit <b>103</b> of the controller <b>100</b> and the authentication processing unit <b>204</b> of the device <b>200</b><i>a </i>perform a mutual authentication process based on a PKI and mutually confirm their validity (step S<b>102</b>).

0158The authentication processing unit <b>103</b> of the controller <b>100</b> and the authentication processing unit <b>204</b> of the device <b>200</b><i>a </i>respectively create shared keys by using a key exchange algorithm (step S<b>102</b>). The shared keys are used in mutual authentication performed thereafter. The process “PKI-based mutual authentication to shared key creation” in step S<b>102</b> described above is illustrated as a subroutine for convenience, and the procedure will be described below. If the return value from the subroutine process is “error”, the controller and the device end the device registration process.

0159Subsequently, the authentication processing unit <b>103</b> of the controller <b>100</b> and the authentication processing unit <b>204</b> of the device <b>200</b><i>a </i>perform mutual authentication using the created shared keys and create session-related information (step S<b>103</b>). Mutual authentication using the shared keys is performed again in step S<b>103</b> also for verifying the shared keys themselves. In step S<b>102</b>, the shared keys are created by using a key exchange algorithm. That is, the controller <b>100</b> and the device <b>200</b><i>a </i>respectively create shared keys by following predetermined procedures. Accordingly, in order to also confirm that the shared keys that have been separately created are the same, performing mutual authentication using the shared keys in step S<b>103</b> is effective.

0160If mutual authentication using the shared keys is successful, a group key, a session key, and a session validity period, which are session-related information, are created (step S<b>103</b>). Further, it is determined whether the device <b>200</b><i>a </i>is set as the reference device (step S<b>103</b>). The process “shared-key-using mutual authentication to session-related information creation” in step S<b>103</b> is illustrated as a subroutine for convenience, and the procedure will be described below. If the return value from the subroutine process is “error”, the controller and the device end the device registration process.

0161The authentication processing unit <b>204</b> of the device <b>200</b><i>a </i>registers the controller ID of the controller <b>100</b> and information about the shared key, group key, and session key that are shared with the controller <b>100</b> in the connecting controller management table <b>1100</b> included in the device information storage unit <b>203</b> via the device management unit <b>201</b>. Further, the authentication processing unit <b>204</b> of the device <b>200</b><i>a </i>registers the session validity period as the remaining session time item in the connecting controller management table <b>1100</b> (step S<b>104</b>).

0162The device management unit <b>101</b> of the controller <b>100</b> transmits to the server <b>300</b> the controller ID and the certificate ID of the public key certificate of the controller <b>100</b>, and the device ID and the certificate ID of the public key certificate of the device <b>200</b><i>a </i>(step S<b>105</b>). At this time, communication with the server is performed through SSL (Secure Socket Layer) communication.

0163The device management unit <b>101</b> of the controller <b>100</b> registers the device ID of the device <b>200</b><i>a </i>and information about the shared key, group key, and session key that are shared with the device <b>200</b><i>a </i>in the connecting device management table <b>1000</b> included in the device information storage unit <b>102</b>. At this time, the device management unit <b>101</b> of the controller <b>100</b> registers the session validity period as the remaining session time item in the connecting device management table <b>1000</b>. In a case where the device <b>200</b><i>a </i>is set as the reference device, the device management unit <b>101</b> of the controller <b>100</b> registers the device <b>200</b><i>a </i>as the reference device in the reference device item in the connecting device management table <b>1000</b> (step S<b>106</b>). In the process “shared-key-using mutual authentication to session-related information creation” in step S<b>103</b>, it is determined whether the device <b>200</b><i>a </i>is to be set as the reference device. A device that is connected to the controller first is set as the reference device, for example.

0164The server <b>300</b> receives information about the controller and the device from the controller <b>100</b> via the communication unit <b>305</b>. The device information management unit <b>301</b> registers the controller ID and the certificate ID related to the controller and the device ID and the certificate ID related to the authenticated device in the device information management table <b>1300</b> included in the device information storage unit <b>302</b> (step S<b>107</b>).

Session Update Process

0165<figref idref="DRAWINGS">FIG. 13</figref> and <figref idref="DRAWINGS">FIG. 14</figref> are flowcharts illustrating examples of procedures of session update processes respectively performed by a device and the controller. <figref idref="DRAWINGS">FIG. 15</figref> is a sequence chart illustrating an example of a procedure of the session update process that includes interaction between devices and the controller.

0166In the session update processes, a device and the controller <b>100</b> respectively perform mutual authentication again and update the group key, session key, and remaining session time. The processes respectively performed by a device and the controller are outlined with reference to the flowcharts in <figref idref="DRAWINGS">FIG. 13</figref> and <figref idref="DRAWINGS">FIG. 14</figref>, and thereafter the process including interaction between devices and the controller is described in detail with reference to the sequence chart in <figref idref="DRAWINGS">FIG. 15</figref>.

0167First, the session update process performed by a device is outlined with reference to the flowchart in <figref idref="DRAWINGS">FIG. 13</figref>. The device performs the process by following a procedure below regardless of whether the device is the reference device or is a device other than the reference device.

0168A device monitors the remaining session time in order to determine whether to start a session update or waits for a session update notification from the controller (step S<b>1210</b>). If the remaining session time is larger than a specific value determined in advance and if no session update notification has been received from the controller (No in step S<b>1210</b>), the device continues monitoring.

0169If the remaining session time decreases to the specific value determined in advance or below or if a session update notification has been received from the controller (Yes in step S<b>1210</b>), the device transmits a session update request to the controller in order to perform a session update (step S<b>1220</b>).

0170The device performs the subroutine “shared-key-using mutual authentication to session-related information creation” to thereby perform mutual authentication with the controller using the shared key, thereafter create a group key and a session key, and set the session validity period, the group key, session key, and session validity period being session-related information (step S<b>1230</b>). The subroutine process will be described in detail below.

0171If the return value from the subroutine in step S<b>1230</b> is “successful” (Yes in step S<b>1240</b>), the device registers the information related to a new session which has been created in step S<b>1230</b> as session update information (step S<b>1250</b>).

0172On the other hand, if the return value from the subroutine in step S<b>1230</b> is “error” (No in step S<b>1240</b>), the device does not perform a session update and ends the session update process.

0173Next, the session update process performed by the controller is outlined with reference to the flowchart in <figref idref="DRAWINGS">FIG. 14</figref>.

0174The controller waits for a session update request from a device (step S<b>1310</b>). If the controller has not received a session update request (No in step S<b>1310</b>), the controller continues waiting for a session update request from a device.

0175If the controller has received a session update request from a device (Yes in step S<b>1310</b>), the controller performs the subroutine “shared-key-using mutual authentication to session-related information creation” to thereby perform mutual authentication with the device using the shared key, thereafter create a group key and a session key, and set the session validity period, the group key, session key, and session validity period being session-related information (step S<b>1320</b>). The subroutine process will be described in detail below.

0176If the return value from the subroutine in step S<b>1320</b> is “successful” (Yes in step S<b>1330</b>), the controller registers the information related to a new session which has been created in step S<b>1320</b> as session update information (step S<b>1340</b>). At this time, in a case where the device is the reference device, the controller registers information indicating that devices other than the device which are connected to the controller have not performed a session update. In a case where the device is not the reference device, the controller registers information indicating that the device has performed a session update. That is, information indicating whether devices other than the reference device have performed a session update or not after a session update by the reference device is managed for each device.

0177On the other hand, if the return value from the subroutine in step S<b>1320</b> is “error” (No in step S<b>1330</b>), the controller does not register session update information to thereby perform no session update for the device.

0178Regardless of whether a session update has been performed for the device, if another device that has not performed a session update is present (Yes in step S<b>1350</b>), the controller transmits a session update notification to the device that has not performed a session update (step S<b>1360</b>). At this time, the controller may simultaneously transmit a session update notification to all devices that have not performed a session update or may transmit a session update notification to some or one of the devices that have not performed a session update. The controller consequently transmits a session update notification to all non-updating devices and performs a session update to thereby update respective sessions with all devices, except for a device for which an error has occurred in step S<b>1320</b> as a matter of course.

0179If the session update process has been completed for all devices (No in step S<b>1350</b>), the controller ends the session update process.

0180Hereinafter, the process including interaction between devices and the controller will be described in more detail with reference to the sequence chart in <figref idref="DRAWINGS">FIG. 15</figref>. Regarding the devices, it is assumed that the device <b>200</b><i>a </i>is the reference device and the device <b>200</b><i>b </i>is a device other than the reference device. The sequence chart illustrates a case where no error occurs, for example, and a process to be performed in a case where an error occurs will be described below.

0181The device management unit <b>201</b> of the device <b>200</b><i>a </i>monitors the remaining session time <b>1160</b> stored in the connecting controller management table <b>1100</b> and checks if the remaining session time is equal to or smaller than a specific threshold determined in advance. If the remaining session time is larger than the specific value, the device management unit <b>201</b> of the device <b>200</b><i>a </i>continues monitoring the remaining session time (step S<b>141</b>). The device management unit <b>201</b> of the device <b>200</b><i>b </i>similarly monitors the remaining session time as the device <b>200</b><i>a </i>does, and it is assumed that the device <b>200</b><i>b </i>has a remaining session time longer than that of the device <b>200</b><i>a</i>. Even if a device other than the reference device has a remaining session time shorter than that of the reference device and performs a session update process ahead of the reference device, there is no problem. In this case, regarding the group key, a group key used by the reference device is obtained in the subroutine “shared-key-using mutual authentication to session-related information creation” described below. That is, the same group key as that currently being used is obtained, and therefore, the group key is not updated. However, at the time when the reference device performs a session update process, the session update state of the device other than the reference device is cleared. As a result, the device is determined to be a session-non-updating device and receives a session update notification from the controller. In response to the notification, the device performs a session update so that the device updates its group key at the timing when the reference device updates its group key.

0182At the time when the remaining session time decreases to the specific threshold or below, the device management unit <b>201</b> of the device <b>200</b><i>a </i>makes the authentication processing unit <b>204</b> perform a session update. The authentication processing unit <b>204</b> first transmits a session update request to the controller <b>100</b> via the communication unit <b>206</b> (step S<b>142</b>).

0183The device management unit <b>101</b> of the controller <b>100</b> receives the session update request via the communication unit <b>105</b> and makes the authentication processing unit <b>103</b> perform a mutual authentication process. In response to this, the authentication processing unit <b>103</b> of the controller <b>100</b> and the authentication processing unit <b>204</b> of the device <b>200</b><i>a </i>perform mutual authentication based on challenge-response authentication using the shared key to thereby mutually confirm their validity (step S<b>143</b>). In a case where their validity has been mutually confirmed through mutual authentication, a group key, a session key, and a session validity period, which are session-related information, are created (step S<b>143</b>).

0184The process “shared-key-using mutual authentication to session-related information creation” in step S<b>143</b> is similar to that in step S<b>103</b> of the device registration process and is illustrated as a subroutine for convenience, and the procedure thereof will be described below. If the return value from the subroutine process is “error”, the controller and the device <b>200</b><i>a </i>do not update the session. That is, the controller and the device <b>200</b><i>a </i>do not perform the session update information registration processes in steps S<b>145</b> and S<b>144</b> respectively, and the flow proceeds to step S<b>146</b>. In the subsequent subroutine “shared-key-using mutual authentication to session-related information creation”, the device <b>200</b><i>b </i>is set as the reference device.

0185The device management unit <b>201</b> of the device <b>200</b><i>a </i>registers the session key, group key, and session validity period created in step S<b>143</b> in the connecting controller management table <b>1100</b> included in the device information storage unit <b>203</b> (step S<b>144</b>). At this time, the session validity period is registered as the remaining session time item.

0186The device management unit <b>101</b> of the controller <b>100</b> registers the group key, session key, and session validity period created in step S<b>143</b> in the connecting device management table <b>1000</b> included in the device information storage unit <b>102</b>. The session validity period is registered as the item of the remaining session time <b>1060</b>. At this time, the session update state <b>1070</b> of the device <b>200</b><i>a </i>is set to “updated”. Regarding records related to devices other than the device <b>200</b><i>a</i>, that is, devices other than the reference device, the item of the session update state <b>1070</b> is updated to “not updated” (step S<b>145</b>).

0187The device management unit <b>101</b> of the controller <b>100</b> refers to the item of the session update state <b>1070</b> in the connecting device management table <b>1000</b> stored in the device information storage unit <b>102</b> and checks if any “not updated” device is present. In a case where a device having the item of the session update state <b>1070</b> being set to “not updated” is not present, the device management unit <b>101</b> of the controller <b>100</b> determines that a session update process has been performed for all devices and ends the process.

0188In a case where a device having the session update state <b>1070</b> being set to “not updated” is present, the device management unit <b>101</b> of the controller <b>100</b> transmits a session update notification to the device (step S<b>146</b>). In the example in <figref idref="DRAWINGS">FIG. 15</figref>, the device management unit <b>101</b> of the controller <b>100</b> transmits a session update notification to the device <b>200</b><i>b </i>that has not performed a session update. If any other device that has not performed a session update is present, the device management unit <b>101</b> of the controller <b>100</b> also transmits a session update notification to the device and thereafter performs the subsequent process. In this case, the device management unit <b>101</b> of the controller <b>100</b> may simultaneously transmit a session update notification to all devices that have not performed a session update, transmit a session update notification to one of the non-updating devices, or transmit a session update notification to every few non-updating devices.

0189The device management unit <b>201</b> of the device <b>200</b><i>b </i>accepts via the communication unit <b>206</b> the session update notification transmitted by the controller <b>100</b> and makes the authentication processing unit <b>204</b> perform a session update. The authentication processing unit <b>204</b> first transmits a session update request to the controller <b>100</b> via the communication unit <b>206</b> (step S<b>147</b>).

0190Thereafter, the device <b>200</b><i>b</i>, which is a device other than the reference device, performs a session update by following a procedure similar to that in steps from S<b>143</b> to S<b>145</b> related to the device <b>200</b><i>a</i>, which is the reference device (steps S<b>148</b> to S<b>150</b>).

0191However, in step S<b>149</b>, the device management unit <b>101</b> of the controller <b>100</b> registers the group key, session key, and session validity period created in step S<b>148</b> in the connecting device management table <b>1000</b> included in the device information storage unit <b>102</b> and updates the item of the session update state <b>1070</b> to “updated” (step S<b>149</b>).

0192By transmitting a session update notification to all session-non-updating devices in step S<b>146</b> described above, the controller performs a session update with all devices and shares the updated group key with all devices.

PKI-Based Mutual Authentication to Shared Key Creation

0193<figref idref="DRAWINGS">FIG. 16</figref> and <figref idref="DRAWINGS">FIG. 17</figref> are flowcharts illustrating examples of procedures of processes from PKI-based mutual authentication to shared key creation respectively performed by a device and the controller. <figref idref="DRAWINGS">FIG. 18</figref> is a sequence chart illustrating an example of a procedure of the process that includes interaction between a device and the controller. The processes respectively performed by a device and the controller are outlined with reference to the flowcharts in <figref idref="DRAWINGS">FIG. 16</figref> and <figref idref="DRAWINGS">FIG. 17</figref>, and thereafter the process including interaction between a device and the controller is described in detail with reference to the sequence chart in <figref idref="DRAWINGS">FIG. 18</figref>.

0194First, the process performed by a device is outlined with reference to the flowchart in <figref idref="DRAWINGS">FIG. 16</figref>.

0195A device waits for the controller ID and the public key certificate from the controller. If the device has not received the controller ID or the public key certificate (No in step S<b>1410</b>) and has received an error (Yes in step S<b>1420</b>), the device sets “error” as the return value of the subroutine (step S<b>1460</b>).

0196If the device has not received the controller ID or the public key certificate and has not received an error from the controller (No in step S<b>1410</b> and No in step S<b>1420</b>), the device continues waiting for information from the controller.

0197If the device has received the controller ID and the public key certificate (Yes in step S<b>1410</b>), the device confirms that the certificate ID of the public key certificate received from the controller is not included in the CRL (step S<b>1430</b>).

0198If the certificate ID is not included in the CRL and has not expired (No in step S<b>1430</b>), the device verifies a signature added to the public key certificate (step S<b>1440</b>).

0199In step S<b>1440</b>, if verification of the signature of the public key certificate of the controller is successful (Yes in step S<b>1440</b>), the device notifies the controller of successful verification (step S<b>1470</b>).

0200Thereafter, the device shares a shared key through a key exchange with the controller (step S<b>1480</b>). The key is used in subsequent mutual authentication. The device sets “successful” as the return value of the subroutine (step S<b>1490</b>).

0201On the other hand, if the certificate ID of the public key certificate is included in the CRL (Yes in step S<b>1430</b>) or if signature verification is not successful (No in step S<b>1440</b>), the device determines that verification of the public key certificate of the controller has failed and transmits an error notification to the controller (step S<b>1450</b>). The device sets “error” as the return value of the subroutine (step S<b>1460</b>).

0202The return value set in step S<b>1490</b> or S<b>1460</b> is returned to the process that has called the subroutine as the result of the subroutine process (step S<b>1500</b>).

0203Next, the process performed by the controller is outlined with reference to the flowchart in <figref idref="DRAWINGS">FIG. 17</figref>.

0204First, the controller confirms that the certificate ID of the public key certificate received from a device is not included in the CRL (step S<b>1610</b>).

0205If the certificate ID is not included in the CRL and has not expired (No in step S<b>1610</b>), the controller verifies a signature added to the public key certificate (step S<b>1620</b>).

0206If the certificate ID of the public key certificate is included in the CRL (Yes in step S<b>1610</b>) or if signature verification is not successful (No in step S<b>1620</b>), the controller determines that verification of the public key certificate of the device has failed and transmits an error notification to the device (step S<b>1630</b>).

0207The controller sets “error” as the return value of the subroutine (step S<b>1670</b>).

0208In step S<b>1620</b>, if verification of the signature of the public key certificate performed by the controller is successful (Yes in step S<b>1620</b>), the controller waits for the result of verification of the public key certificate of the controller performed by the device (step S<b>1650</b>).

0209If the controller has not received a successful verification notification from the device (No in step S<b>1650</b>) and has received an error notification (Yes in step S<b>1660</b>), the controller sets “error” as the return value of the subroutine (step S<b>1670</b>).

0210If the controller has not received a successful verification notification from the device (No in step S<b>1650</b>) and has not received an error from the device (No in step S<b>1660</b>), the controller continues waiting for the result of verification from the device.

0211If the controller has received a successful verification notification from the device (Yes in step S<b>1650</b>), the controller and the device share a shared key through a key exchange (step S<b>1680</b>). The key is used in subsequent mutual authentication.

0212The controller sets “successful” as the return value of the subroutine (step S<b>1690</b>).

0213The return value set in step S<b>1690</b> or S<b>1670</b> is returned to the process that has called the subroutine as the result of the subroutine process (step S<b>1700</b>).

0214Hereinafter, the details of the process including interaction between a device and the controller will be described with reference to the sequence chart in <figref idref="DRAWINGS">FIG. 18</figref>. Although description will be given while assuming the device <b>200</b><i>a </i>to be the device, for example, the process related to the device <b>200</b><i>b </i>and the device <b>200</b><i>c </i>is performed by following a procedure similar to that for the device <b>200</b><i>a </i>as a matter of course. The sequence chart illustrates a case where no error occurs, for example, and a process to be performed in a case where an error occurs will be described below.

0215The authentication processing unit <b>103</b> of the controller <b>100</b> confirms that the certificate ID of the public key certificate of the device <b>200</b><i>a </i>is not included in the CRL stored in the authentication information storage unit <b>104</b> (step S<b>111</b>).

0216In step S<b>111</b>, if the certificate ID related to the device <b>200</b><i>a </i>is not included in the CRL, the authentication processing unit <b>103</b> of the controller <b>100</b> verifies if an electronic signature of a certifying authority which is added to the public key certificate of the device <b>200</b><i>a </i>is valid (step S<b>112</b>). An electronic signature scheme and a verification method used here are based on the ECDSA (Elliptic Curve Digital Signature Algorithm). The electronic signature and the verification method based on the ECDSA use a general technique described in National Security Agency, “Suite B Implementer's Guide to FIPS 186-3 (ECDSA)”, [online], Feb. 3, 2010, [searched on Jun. 24, 2014], Internet <URL: http://www.nsa.gov/ia/_files/ecdsa.pdf> and the like, and therefore, description thereof will be omitted.

0217If the certificate ID related to the device <b>200</b><i>a </i>is included in the CRL in step S<b>111</b> or if verification of the electronic signature is not successful in step S<b>112</b>, the authentication processing unit <b>103</b> determines that the device <b>200</b><i>a </i>is not a valid device, transmits an error notification to the device <b>200</b><i>a</i>, and returns the return value “error” to the device registration process, which has called the subroutine. At this time, the device <b>200</b><i>a </i>that has received the error notification also returns the return value “error”, and both the controller and the device end the subroutine process.

0218If verification of the electronic signature is successful in step S<b>112</b>, the authentication processing unit <b>103</b> of the controller <b>100</b> determines that the device <b>200</b><i>a </i>is a valid device and transmits the controller ID and the public key certificate of the controller to the device <b>200</b><i>a </i>via the communication unit <b>105</b> (step S<b>113</b>).

0219The device management unit <b>201</b> of the device <b>200</b><i>a </i>accepts via the communication unit <b>206</b> the controller ID and the public key certificate of the controller <b>100</b> and makes the authentication processing unit <b>204</b> perform an authentication process based on a PKI. The authentication processing unit <b>204</b> first confirms that the certificate ID of the public key certificate of the controller is not included in the CRL stored in the authentication information storage unit <b>205</b> (step S<b>114</b>).

0220In step S<b>114</b>, if the certificate ID related to the controller <b>100</b> is not included in the CRL, the authentication processing unit <b>204</b> of the device <b>200</b><i>a </i>verifies if an electronic signature of a certificating authority which is added to the public key certificate of the controller <b>100</b> is valid (step S<b>115</b>). An electronic signature scheme and a verification method used here are based on the ECDSA (Elliptic Curve Digital Signature Algorithm) as in step S<b>112</b>, and description thereof will be omitted.

0221If the certificate ID related to the controller is included in the CRL in step S<b>114</b> or if verification of the electronic signature is not successful in step S<b>115</b>, the authentication processing unit <b>204</b> determines that the controller <b>100</b> is not a valid device, transmits an error notification to the controller, and returns the return value “error” to the device registration process, which has called the subroutine. At this time, the controller that has received the error notification also returns the return value “error”, and both the controller and the device end the subroutine process.

0222If verification of the electronic signature is successful in step S<b>115</b>, the authentication processing unit <b>204</b> of the device <b>200</b><i>a </i>determines that the controller <b>100</b> is a valid device and transmits a successful verification notification to the controller <b>100</b> (step S<b>116</b>).

0223Next, the authentication processing unit <b>204</b> of the device <b>200</b><i>a </i>and the authentication processing unit <b>103</b> of the controller <b>100</b> perform a key exchange as a process for sharing a shared key (steps S<b>117</b> and S<b>118</b>). A key exchange algorithm used here is based on ECDH (Elliptic Curve Diffie-Hellman), which is a key exchange algorithm using elliptic curve cryptography. ECDH uses a general technique described in Elaine Barker and three others, NIST Special Publication 800-56A Revision 2, “Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography”, [online], May 13, 2013, National Institute of Standards and Technology, [searched on Jun. 24, 2014], Internet <URL: http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar2.pdf> and the like, and therefore, detailed description thereof will be omitted.

0224In the key exchange based on ECDH, the authentication processing unit <b>103</b> of the controller <b>100</b> calculates a value by using the private key of the controller and the public key of the device <b>200</b><i>a </i>which is included in the public key certificate of the device <b>200</b><i>a </i>and performing a predetermined procedure. The authentication processing unit <b>204</b> of the device <b>200</b><i>a </i>calculates a value by using the private key of the device and the public key of the controller <b>100</b> which is included in the public key certificate of the controller <b>100</b> and performing a predetermined procedure. Here the resulting values respectively calculated by the controller <b>100</b> and the device <b>200</b><i>a </i>are the same. A shared key is calculated from the values thus shared. In this embodiment, a key length of 128 bits based on AES (Advanced Encryption Standard) is employed for a shared key, a hash value is calculated from the values thus shared, and the most significant 128 bits of the calculated hash value are used as a shared key.

Shared-Key-Using Mutual Authentication to Session-Related Information Creation

0225<figref idref="DRAWINGS">FIG. 19</figref> and <figref idref="DRAWINGS">FIG. 20</figref> are flowcharts illustrating examples of procedures of processes from shared-key-using mutual authentication to session-related information creation respectively performed by a device and the controller. <figref idref="DRAWINGS">FIG. 21</figref> is a sequence chart illustrating an example of a procedure of the process that includes interaction between a device and the controller.

0226In this embodiment, as mutual authentication using a shared key, challenge-response authentication using random numbers is performed.

0227The processes respectively performed by a device and the controller are outlined with reference to the flowcharts in <figref idref="DRAWINGS">FIG. 19</figref> and <figref idref="DRAWINGS">FIG. 20</figref>, and thereafter the process including interaction between a device and the controller is described in detail with reference to the sequence chart in <figref idref="DRAWINGS">FIG. 21</figref>.

0228First, the process from shared-key-using mutual authentication to session-related information creation performed by a device is outlined with reference to the flowchart in <figref idref="DRAWINGS">FIG. 19</figref>.

0229A device waits for random numbers A created by the controller to be received from the controller. If the device has not received the random numbers A (No in step S<b>1810</b>), the device continues waiting.

0230If the device has received the random numbers A (Yes in step S<b>1810</b>), the device encrypts the received random numbers A and creates random numbers B, which are different from the random numbers A (step S<b>1820</b>).

0231The device transmits encrypted random numbers A′, which are the encrypted random numbers A, and the random numbers B to the controller (step S<b>1830</b>).

0232Thereafter, the device waits for the controller to perform processing. If the device has not received encrypted random numbers B′, an encrypted session key, an encrypted group key, or a session validity period from the controller (No in step S<b>1840</b>) and has received an error from the controller (Yes in step S<b>1850</b>), the device sets “error” as the return value of the subroutine (step S<b>1880</b>).

0233If the device has not received the encrypted random numbers B′, the encrypted session key, the encrypted group key, or the session validity period from the controller (No in step S<b>1840</b>) and has not received an error from the controller (No in step S<b>1850</b>), the device continues waiting for any of the pieces of information to be received from the controller.

0234If the device has received the encrypted random numbers B′, the encrypted session key, the encrypted group key, and the session validity period from the controller (Yes in step S<b>1840</b>), the device first performs verification of the random numbers B (step S<b>1860</b>). The device decrypts the received encrypted random numbers B′ using the shared key retained by the device. If the value obtained as a result of decryption matches the random numbers B created by the device in step S<b>1820</b>, the device determines that verification of the random numbers B is successful.

0235If verification of the random numbers B is not successful (No in step S<b>1860</b>), the device notifies the controller of the error (step S<b>1870</b>).

0236The device sets “error” as the return value of the subroutine (step S<b>1880</b>).

0237If verification of the random numbers B is successful (Yes in step S<b>1860</b>), the device decrypts the group key and session key received from the controller (step S<b>1890</b>).

0238The device notifies the controller of successful verification (step S<b>1900</b>).

0239The device sets “successful” as the return value of the subroutine (step S<b>1910</b>).

0240The return value set in step S<b>1910</b> or S<b>1880</b> is returned to the process that has called the subroutine as the result of the subroutine process (step S<b>1920</b>).

0241Next, the process from shared-key-using mutual authentication to session-related information creation performed by the controller is outlined with reference to the flowchart in <figref idref="DRAWINGS">FIG. 20</figref>.

0242The controller creates random numbers A and transmits the random numbers A to a device (step S<b>2010</b>).

0243The controller waits for encrypted random numbers A′ and random numbers B created by the device performing processing. If the controller has not received the encrypted random numbers A′ or the random numbers B from the device (No in step S<b>2020</b>), the controller continues waiting until the controller receives the encrypted random numbers A′ and the random numbers B.

0244If the controller has received the encrypted random numbers A′ and the random numbers B (Yes in step S<b>2020</b>), the controller performs verification of the random numbers A (step S<b>2030</b>). The controller decrypts the received encrypted random numbers A′ using the shared key retained by the controller. If the value obtained as a result of decryption matches the random numbers A created by the controller in step S<b>2010</b>, the controller determines that verification of the random numbers A is successful.

0245If verification of the random numbers A is not successful (No in step S<b>2030</b>), the controller notifies the device of the error (step S<b>2040</b>). The controller sets “error” as the return value of the subroutine (step S<b>2150</b>).

0246If verification of the random numbers A is successful (Yes in step S<b>2030</b>), the controller encrypts the random numbers B received from the device (step S<b>2050</b>).

0247The controller checks if the device is the reference device (step S<b>2060</b>). In a case where the device is a first device that makes a connection request to the controller or in a case where a connection with a device that is the reference device is lost, for example, and the reference device is not set, the device is assumed to be the reference device.

0248If the device is the reference device (Yes in step S<b>2060</b>), the controller creates a group key (step S<b>2070</b>). On the other hand, if the device is not the reference device (No in step S<b>2060</b>), in order to share the group key created and retained by the controller also with the device, the controller obtains data about the group key (step S<b>2080</b>).

0249The controller creates a session key and sets the session validity period (step S<b>2090</b>).

0250The controller encrypts the group key and the session key using the shared key (step S<b>2100</b>).

0251Thereafter, the controller transmits the encrypted random numbers B′, the encrypted session key, the encrypted group key, and the session validity period obtained as a result of the process in steps from S<b>2050</b> to S<b>2100</b> to the device (step S<b>2110</b>).

0252The controller waits for the result of verification performed by the device. If the controller has not received a successful verification notification (No in step S<b>2120</b>) and has received an error (Yes in step S<b>2140</b>), the controller sets “error” as the return value of the subroutine (step S<b>2150</b>).

0253If the controller has not received a successful verification notification from the device (No in step S<b>2120</b>) and has not received an error from the device (No in step S<b>2140</b>), the controller continues waiting for a result from the device.

0254If the controller has received a successful verification notification from the device (Yes in step S<b>2120</b>), the controller sets “successful” as the return value of the subroutine (step S<b>2130</b>).

0255The return value set in step S<b>2130</b> or S<b>2150</b> is returned to the process that has called the subroutine (step S<b>2160</b>).

0256Hereinafter, the details of the process including interaction between a device and the controller will be described with reference to the sequence chart in <figref idref="DRAWINGS">FIG. 21</figref>. Although description will be given while assuming the device <b>200</b><i>a </i>to be the device, the process related to the device <b>200</b><i>b </i>and the device <b>200</b><i>c </i>is performed by following a procedure similar to that for the device <b>200</b><i>a </i>as a matter of course. The sequence chart illustrates a case where no error occurs, for example, and a process to be performed in a case where an error occurs will be described below.

0257First, the authentication processing unit <b>103</b> of the controller <b>100</b> creates any random numbers A and transmits the random numbers A to the device <b>200</b><i>a </i>(step S<b>121</b>).

0258The authentication processing unit <b>204</b> of the device <b>200</b><i>a </i>encrypts the random numbers A received via the communication unit <b>206</b> using the shared key retained by the device <b>200</b><i>a </i>and creates encrypted random numbers A′ (step S<b>122</b>). The authentication processing unit <b>204</b> creates any random numbers B (step S<b>122</b>).

0259The authentication processing unit <b>204</b> of the device <b>200</b><i>a </i>transmits the encrypted random numbers A′ encrypted in step S<b>122</b> and the random numbers B to the controller <b>100</b> (step S<b>123</b>).

0260The authentication processing unit <b>103</b> of the controller <b>100</b> receives the encrypted random numbers A′ and the random numbers B. The authentication processing unit <b>103</b> decrypts the encrypted random numbers A′ using the shared key. If the value obtained as a result of decryption matches the random numbers A created by the controller in step S<b>121</b>, the authentication processing unit <b>103</b> determines that verification of the random numbers A is successful (step S<b>124</b>).

0261In step S<b>124</b>, if verification of the random numbers A is not successful, the authentication processing unit <b>103</b> of the controller transmits an error notification to the device and returns the return value “error” to the process that has called the subroutine. At this time, the device that has received the error notification also returns the return value “error”, and both the controller and the device end the subroutine process.

0262In step S<b>124</b>, if verification of the random numbers A is successful, the authentication processing unit <b>103</b> of the controller encrypts the random numbers B received from the device <b>200</b><i>a </i>using the shared key and creates encrypted random numbers B′ (step S<b>125</b>).

0263Subsequently, the authentication processing unit <b>103</b> of the controller refers to the item of the reference device <b>1080</b> in the connecting device management table <b>1000</b> in the device information storage unit <b>102</b> and checks if the device <b>200</b><i>a </i>is the reference device. If the device <b>200</b><i>a </i>is the reference device, the authentication processing unit <b>103</b> creates a group key (step S<b>126</b>). The group key has a key length of 128 bits based on AES and is created by using any general technique, and therefore, description of creation will be omitted. In a case where the device <b>200</b><i>a </i>is a first device that makes a connection request to the controller or in a case where a connection with a device that is the reference device is lost, for example, and the reference device is not set, the authentication processing unit <b>103</b> sets the device <b>200</b><i>a </i>as the reference device and creates a group key.

0264On the other hand, in a case where the authentication processing unit <b>103</b> refers to the connecting device management table <b>1000</b> and confirms that the device <b>200</b><i>a </i>is not the reference device, the authentication processing unit <b>103</b> obtains, from the connecting device management table <b>1000</b> stored in the device information storage unit <b>102</b>, information about the group key that has been created.

0265The authentication processing unit <b>103</b> of the controller creates a session key (step S<b>127</b>). The session key is similar to the group key, that is, has a key length of 128 bits based on AES, and is created by using any general technique.

0266Subsequently, the authentication processing unit <b>103</b> of the controller sets the session validity period (step S<b>128</b>). At this time, the authentication processing unit <b>103</b> sets a specific value determined in advance (24 hours or 72 hours, for example) as the session validity period.

0267The authentication processing unit <b>103</b> of the controller encrypts information about the group key and session key respectively obtained in steps S<b>126</b> and S<b>127</b> by using the shared key (step S<b>129</b>).

0268The authentication processing unit <b>103</b> transmits the encrypted random numbers B′ encrypted in step S<b>125</b>, the encrypted group key and encrypted session key encrypted in step S<b>129</b>, and the session validity period set in step S<b>128</b> to the device <b>200</b><i>a </i>via the communication unit <b>105</b> (step S<b>130</b>).

0269The authentication processing unit <b>204</b> of the device <b>200</b><i>a </i>verifies the encrypted random numbers B′ received from the controller <b>100</b> (step S<b>131</b>). The authentication processing unit <b>204</b> decrypts the encrypted random numbers B′ using the shared key retained by the device <b>200</b><i>a</i>. If the value obtained as a result of decryption matches the random numbers B created by the device <b>200</b><i>a </i>in step S<b>122</b>, the authentication processing unit <b>204</b> determines that verification of the random numbers B is successful.

0270In step S<b>131</b>, if verification of the random numbers B is not successful, the authentication processing unit <b>204</b> determines that the controller <b>100</b> is not a valid controller, transmits an error notification to the controller <b>100</b>, and returns the return value “error” to the process that has called the subroutine. At this time, the controller that has received the error notification also returns the return value “error”, and both the controller and the device end the subroutine process.

0271In step S<b>131</b>, if verification of the random numbers B is successful, the authentication processing unit <b>204</b> of the device <b>200</b><i>a </i>decrypts the encrypted group key and the encrypted session key using the shared key (step S<b>132</b>).

0272The authentication processing unit <b>204</b> of the device <b>200</b><i>a </i>notifies the controller <b>100</b> of successful verification (step S<b>133</b>).

Device History Information Transmission Process

0273<figref idref="DRAWINGS">FIG. 22</figref> is a sequence chart illustrating an example of a procedure for transmitting device history information from the device <b>200</b><i>a </i>to the server <b>300</b>. Such transmission of device history information is performed at regular or irregular intervals. Although the procedure related to the device <b>200</b><i>a </i>will be described below, for example, the procedure of the process related to the device <b>200</b><i>b </i>and the device <b>200</b><i>c </i>is similar to that related to the device <b>200</b><i>a. </i>

0274The device management unit <b>201</b> of the device encrypts device history information accumulated in the device history storage unit <b>202</b> using the session key and transmits the result to the controller <b>100</b> together with the device ID of the device (step S<b>161</b>).

0275The device management unit <b>101</b> of the controller <b>100</b> receives the device ID and the encrypted device history information via the communication unit <b>105</b>. The device management unit <b>101</b> of the controller <b>100</b> obtains the session key associated with the device ID from the connecting device management table <b>1000</b> included in the device information storage unit <b>102</b> and decrypts the received device history information (step S<b>162</b>).

0276The communication unit <b>105</b> of the controller <b>100</b> and the communication unit <b>305</b> of the server <b>300</b> perform SSL authentication and establish an encrypted communication channel (step S<b>163</b>). Here, SSL authentication is performed using a general technique, and therefore, description thereof will be omitted.

0277The device management unit <b>101</b> of the controller <b>100</b> transmits the controller ID of the controller, the device ID received from the device, and the decrypted device history information to the server <b>300</b> via the communication unit <b>105</b> (step S<b>164</b>).

0278The device information management unit <b>301</b> of the server <b>300</b> registers the controller ID, the device ID, and the device history information received via the communication unit <b>305</b> in the device information management table <b>1300</b> included in the device information storage unit <b>302</b> (step S<b>165</b>).

Control Information Transmission Process

0279<figref idref="DRAWINGS">FIG. 23</figref> is a sequence chart illustrating an example of a procedure for the server <b>300</b> to control the device <b>200</b><i>a</i>. The server <b>300</b> transmits control request information for controlling the device <b>200</b><i>a </i>to the controller <b>100</b>. The controller <b>100</b> that has accepted the control request creates and transmits a control command to the device <b>200</b><i>a </i>and makes the device <b>200</b><i>a </i>execute a function corresponding to the control request. Such a control request from the server <b>300</b> to the device <b>200</b><i>a </i>is made at regular or irregular intervals. The control request includes a function to be executed by the device, content to be displayed on a display, and so on, for example.

0280Although the procedure related to the device <b>200</b><i>a </i>will be described below, for example, the procedure of the process related to the device <b>200</b><i>b </i>and the device <b>200</b><i>c </i>is similar to that related to the device <b>200</b><i>a. </i>

0281The communication unit <b>305</b> of the server <b>300</b> and the communication unit <b>105</b> of the controller <b>100</b> perform SSL authentication and establish an encrypted communication channel (step S<b>171</b>).

0282The device information management unit <b>301</b> of the server <b>300</b> creates control request information for making the device <b>200</b><i>a </i>perform a certain operation and transmits the control request information to the controller <b>100</b> via the communication unit <b>305</b> (step S<b>172</b>).

0283The device management unit <b>101</b> of the controller <b>100</b> receives the control request information via the communication unit <b>105</b>. The device management unit <b>101</b> checks the control request information to determine what control request is made to which device in the network, and creates a control command for execution by the device <b>200</b><i>a </i>in accordance with the control request (step S<b>173</b>).

0284In a case where the control command created in step S<b>173</b> is an instruction given to a plurality of devices, the device management unit <b>101</b> of the controller <b>100</b> encrypts the control command using the group key (step S<b>174</b>). At this time, the device management unit <b>101</b> of the controller <b>100</b> may add information indicating that encryption using the group key has been performed to the header portion of the control command to be transmitted.

0285In a case where the control command created in step S<b>173</b> is an instruction given to a single device, the device management unit <b>101</b> of the controller <b>100</b> encrypts the control command using the session key (step S<b>175</b>). At this time, the device management unit <b>101</b> of the controller <b>100</b> may add information indicating that encryption using the session key has been performed to the header portion of the control command to be transmitted.

0286The communication unit <b>105</b> of the controller <b>100</b> transmits the control command encrypted using the group key or the session key to the target device or devices (step S<b>176</b>).

0287The device <b>200</b><i>a </i>receives the encrypted control command via the communication unit <b>206</b> and decrypts the control command using the group key or the session key (step S<b>177</b>). At this time, determination as to whether decryption is to be performed using the group key or the session key may be performed by using the information added to the header portion in step S<b>174</b> or S<b>175</b>. Alternatively, the device <b>200</b><i>a </i>may decrypt the control command by using each of the group key and the session key and perform determination on the basis of the result of the decryption. For example, the controller <b>100</b> adds a MAC (Message Authentication Code) value to the encrypted control command to be transmitted. The device decrypts the encrypted control command that has been received using each of the group key and the session key. The device calculates MAC values from the decrypted control commands respectively and determines which key has been used to calculate a MAC value that matches the MAC value received from the controller. The device determines that a decryption result that corresponds to the matching MAC value is a correct control command.

0288The device performs an operation in accordance with the instruction of the decrypted control command (step S<b>178</b>).

1.4 Conclusion

0289In this embodiment, a device among a plurality of devices connected to the controller is set as the reference device, and the controller sends an update notification to devices other than the reference device at the timing of a group key update by the reference device to thereby make the other devices update their group keys. Accordingly, it is possible to make the plurality of devices connected to the controller update their group keys at the same timing, and even if the controller and the devices perform mutual authentication and a group key update, the controller can simultaneously transmit encrypted information to the devices.

0290In mutual authentication between the controller and a device, two types of procedures are employed. In a case of making a connection between the controller and a device, mutual authentication using a public key certificate based on a PKI is performed. In a case of subsequent session update processing, mutual authentication using a shared key is performed. In general, mutual authentication using a shared key involves a lower processing load compared to mutual authentication based on a PKI. Accordingly, by employing a procedure using a shared key as a mutual authentication process to be performed upon a session update, a processing load related to mutual authentication can be reduced.

2. Second Embodiment

2-1. Overview

0291An authentication system according to this embodiment is different in that the controller sets the remaining session times for respective devices so that the remaining session times that are set at the same time point have the same value.

0292Hereinafter, any constituent element similar to that in the first embodiment is assigned the same reference numeral for convenience of description. Description of any constituent element similar to that in the first embodiment will be omitted, and description focusing on differences will be given.

2-2. Configurations

0293The configurations of an authentication system, a controller, devices, and a server in this embodiment are similar to the configurations of the authentication system <b>10</b>, the controller <b>100</b>, the devices <b>200</b><i>a </i>to <b>200</b><i>c</i>, and the server <b>300</b> in the first embodiment respectively. However, the connecting device management table stored in the device information storage unit <b>102</b> of the controller <b>100</b> has a data structure partially different from that in the first embodiment.

0294<figref idref="DRAWINGS">FIG. 24</figref> is a diagram illustrating an example of a data structure and data of a connecting device management table <b>2000</b> in this embodiment.

0295The connecting device management table <b>2000</b> includes a group of connecting device management records, which are data for respective connected devices. Each record includes items, namely, a device ID <b>2010</b>, a certificate ID <b>2020</b>, a shared key <b>2030</b>, a group key <b>2040</b>, a session key <b>2050</b>, a remaining session time <b>2060</b>, a session update state <b>2070</b>, and a reference device <b>2080</b>. A difference from the first embodiment is that a common value is set as the remaining session time <b>2060</b> for devices having the same group key <b>2040</b>. For example, in <figref idref="DRAWINGS">FIG. 24</figref>, the device ID<b>1</b> and the device ID<b>2</b> retain the same group key “11223 . . . ”, and therefore, also have the same value “13:40:50” as the remaining session time.

2-3. Operations

0296In this embodiment, the authentication system <b>10</b> performs “device registration process”, “session update process”, “PKI-based mutual authentication to shared key creation”, “shared-key-using mutual authentication to session-related information creation”, “device history information transmission process”, and “control information transmission process” as in the first embodiment. The procedure of “shared-key-using mutual authentication to session-related information creation” is described first, and the other processes are described one by one while differences from the first embodiment are focused.

Shared-Key-Using Mutual Authentication to Session-Related Information Creation

0297The controller and a device perform mutual authentication using the shared key and create session-related information, namely, a group key, a session key, and a session validity period by performing the process from step S<b>121</b> to step S<b>133</b> in the sequence chart in <figref idref="DRAWINGS">FIG. 21</figref> as in the first embodiment.

0298However, the controller <b>100</b> sets the session validity period in step S<b>128</b> in a manner different from that in the first embodiment.

0299In this embodiment, the authentication processing unit <b>103</b> of the controller <b>100</b> sets a specific value determined in advance (24 hours or 72 hours, for example) as the session validity period in a case where the device is the reference device. However, in a case where the device is not the reference device, the authentication processing unit <b>103</b> of the controller <b>100</b> sets the session validity period as follows (step S<b>128</b>).

0300The authentication processing unit <b>103</b> of the controller <b>100</b> refers to the remaining session time <b>2060</b> in the connecting device management table <b>2000</b> included in the device information storage unit <b>102</b> and obtains the remaining session time of the reference device. The authentication processing unit <b>103</b> of the controller <b>100</b> sets the obtained value as the remaining session time of the device.

0301Description is given while referring to data in the connecting device management table <b>2000</b> illustrated in <figref idref="DRAWINGS">FIG. 24</figref>, for example. In a case of setting the session validity period of the device having device ID<b>2</b>, which is not the reference device, the authentication processing unit <b>103</b> of the controller <b>100</b> obtains the remaining session time of the device ID<b>1</b>, which is the reference device, from the connecting device management table <b>2000</b> and sets the obtained value as the session validity period of the device ID<b>2</b>.

0302As described above, by setting the session validity period of a device that is not the reference device to the remaining session period of the reference device at the time of setting the session validity period, the reference device and the device other than the reference device consequently have remaining session times that are approximately the same.

Device Registration Process

0303The controller and a device perform the processes of making a connection request, PKI-based mutual authentication to shared key creation, shared-key-using mutual authentication to session-related information creation, and registration of the controller and device by performing the process from step S<b>101</b> to step S<b>107</b> in the sequence chart in <figref idref="DRAWINGS">FIG. 12</figref> as in the first embodiment.

0304As described in the above-described procedure “shared-key-using mutual authentication to session-related information creation”, the remaining session time of the reference device is set as the session validity period of a device other than the reference device in step S<b>103</b>.

0305In step S<b>104</b>, regarding the session validity period that is registered by the device, the session validity period received from the controller <b>100</b> is registered as the remaining session time regardless of whether the device is the reference device or not, as in the first embodiment.

0306In step S<b>106</b>, when the controller performs device registration of a device that is not the reference device, the controller may register the item of the remaining session time by sharing the remaining session time of the reference device or may register the session validity period set in step S<b>103</b> as the remaining session time. In a case of registration using any of the manners described above, the process in steps S<b>104</b> and S<b>106</b> in the sequence chart in <figref idref="DRAWINGS">FIG. 12</figref> is performed immediately after the process in step S<b>103</b> in the sequence chart in <figref idref="DRAWINGS">FIG. 12</figref>. Consequently, the remaining session times related to the reference device and a device other than the reference device set in the connecting device management table <b>2000</b> of the controller <b>100</b> has approximately the same value as that of the remaining session time set in the connecting device management table <b>1100</b> of the device.

Session Update Process

0307<figref idref="DRAWINGS">FIG. 25</figref> and <figref idref="DRAWINGS">FIG. 26</figref> are flowcharts illustrating examples of procedures of session update processes respectively performed by a device and the controller in this embodiment. <figref idref="DRAWINGS">FIG. 27</figref> is a sequence chart illustrating an example of a procedure of the session update process that includes interaction between a device and the controller.

0308The processes respectively performed by a device and the controller are outlined with reference to the flowcharts in <figref idref="DRAWINGS">FIG. 25</figref> and <figref idref="DRAWINGS">FIG. 26</figref>, and thereafter the process including interaction between a device and the controller is described in detail with reference to the sequence chart in <figref idref="DRAWINGS">FIG. 27</figref>.

0309First, the session update process performed by a device is outlined with reference to the flowchart in <figref idref="DRAWINGS">FIG. 25</figref>.

0310A device monitors the remaining session time set with the controller and determines whether the remaining session time is equal to or smaller than a specific value determined in advance (step S<b>3010</b>). If the remaining session time is larger than the specific value (No in step S<b>3010</b>), the device continues monitoring.

0311If the remaining session time is smaller than the specific value determined in advance (Yes in step S<b>3010</b>), the device transmits a session update request to the controller in order to perform a session update (step S<b>3020</b>).

0312The device performs the subroutine “shared-key-using mutual authentication to session-related information creation” to thereby perform mutual authentication with the controller using the shared key, thereafter create a group key and a session key, and set the session validity period, the group key, session key, and session validity period being session-related information (step S<b>3030</b>).

0313If the return value from the subroutine in step S<b>3030</b> is “successful” (Yes in step S<b>3040</b>), the device registers the information related to a new session which has been created in step S<b>3030</b> as session update information (step S<b>3050</b>).

0314On the other hand, if the return value from the subroutine in step S<b>3030</b> is “error” (No in step S<b>3040</b>), the device does not perform a session update and ends the session update process.

0315Next, the session update process performed by the controller is outlined with reference to the flowchart in <figref idref="DRAWINGS">FIG. 26</figref>.

0316The controller waits for a session update request from a device (step S<b>3110</b>). If the controller has not received a session update request (No in step S<b>3110</b>), the controller continues waiting for a session update request from a device.

0317If the controller has received a session update request from a device (Yes in step S<b>3110</b>), the controller performs the subroutine “shared-key-using mutual authentication to session-related information creation” to thereby perform mutual authentication with the device using the shared key and thereafter set the group key, session key, and session validity period, which are session-related information (step S<b>3120</b>).

0318If the return value from the subroutine in step S<b>3120</b> is “successful” (Yes in step S<b>3130</b>), the controller registers the information related to a new session which has been created in step S<b>3120</b> as session update information (step S<b>3140</b>).

0319On the other hand, if the return value from the subroutine in step S<b>3120</b> is “error” (No in step S<b>3130</b>), the controller does not perform a session update for the device that is performing a session update.

0320If another device that has not performed a session update is present (Yes in step S<b>3150</b>), the flow returns to the first step, and the controller waits for a session update request from the device that has not performed a session update (step S<b>3110</b>).

0321If the session update process has been completed for all devices (No in step S<b>3150</b>), the controller ends the session update process.

0322Hereinafter, the process including interaction between devices and the controller will be described with reference to the sequence chart in <figref idref="DRAWINGS">FIG. 27</figref> while differences from the first embodiment are focused. Regarding the devices, it is assumed that the device <b>200</b><i>a </i>is the reference device and the device <b>200</b><i>b </i>is a device other than the reference device, for example.

0323The device management unit <b>201</b> of a device instructs the authentication processing unit <b>204</b> to perform a session update at the time when the remaining session time decreases to a specific threshold or below. The authentication processing unit <b>204</b> that accepts the instruction transmits a session update request to the controller <b>100</b> via the communication unit <b>206</b> (steps S<b>202</b> and S<b>207</b>).

0324Here, in this embodiment, a device other than the reference device has a remaining session time that is approximately the same as the remaining session time of the reference device. Therefore, the process in step S<b>202</b> and the process in step S<b>207</b> are performed at the approximately the same timing, and the controller consequently performs a group key update with the respective devices at approximately the same timings.

0325The processes “PKI-based mutual authentication to shared key creation”, “device history information transmission process”, and “control information transmission process” are similar to those in the first embodiment, and therefore, description thereof will be omitted.

2-4. Conclusion

0326In the authentication system according to this embodiment, by setting the session validity period of a device other than the reference device on the basis of the remaining session time of the reference device at the time of setting the session validity period, the reference device and a device other than the reference device consequently have remaining session times that are approximately the same. Accordingly, the devices perform a session update process on the basis of the remaining session times and consequently perform a group key update at approximately the same timings respectively. As a result, even if the controller and the devices perform mutual authentication and a group key update, the controller can simultaneously transmit encrypted information to the devices.

3. Third Embodiment

3-1. Overview

0327An authentication system according to this embodiment is different in that the controller and the devices each have two types of group keys, namely, a group key that is currently used and a group key that is used after an update.

0328Hereinafter, any constituent element similar to that in the above-described embodiments is assigned the same reference numeral for convenience of description. Further, description of any constituent element similar to that in the above-described embodiments will be omitted, and description focusing on differences will be given.

3-2. Configurations

0329The configurations of an authentication system, a controller, devices, and a server in this embodiment are similar to the configurations of the authentication system <b>10</b>, the controller <b>100</b>, the devices <b>200</b><i>a </i>to <b>200</b><i>c</i>, and the server <b>300</b> in the second embodiment respectively. However, the connecting device management table stored in the device information storage unit <b>102</b> of the controller <b>100</b> has a data structure partially different from that in the above-described embodiments, and the connecting controller management table stored in the device information storage unit <b>203</b> of the device also has a data structure partially different from that in the above-described embodiments.

0330<figref idref="DRAWINGS">FIG. 28</figref> is a diagram illustrating an example of a data structure and data of a connecting device management table <b>3000</b> included in the device information storage unit <b>102</b> of the controller <b>100</b> in this embodiment.

0331The connecting device management table <b>3000</b> includes a group of connecting device management records, which are data for respective connected devices. Each record includes items, namely, a device ID <b>3010</b>, a certificate ID <b>3020</b>, a shared key <b>3030</b>, a group key (current) <b>3040</b>, a group key (new) <b>3050</b>, a session key <b>3060</b>, a remaining session time <b>3070</b>, a session update state <b>3080</b>, and a reference device <b>3090</b>. For the group key, two items of the group key (current) and the group key (new) are provided.

0332<figref idref="DRAWINGS">FIG. 29</figref> is a diagram illustrating an example of a data structure and data of a connecting controller management table <b>3100</b> included in the device information storage unit <b>203</b> of the device in this embodiment.

0333The connecting controller management table <b>3100</b> includes a group of connecting controller management records, which are data for respective connected controllers. Each record includes items, namely, a controller ID <b>3110</b>, a certificate ID <b>3120</b>, a shared key <b>3130</b>, a group key (current) <b>3140</b>, a group key (new) <b>3150</b>, a session key <b>3160</b>, and a remaining session time <b>3170</b>. For the group key, two items of the group key (current) and the group key (new) are provided as in the connecting device management table <b>3000</b>.

0334Here, information to be simultaneously transmitted to the devices by the controller is encrypted by using the encryption key that is retained by the controller and the devices as the group key (current). The group key (new) is an item for retaining a group key newly created in a session update process performed by the controller and the reference device.

3-3. Operations

0335In this embodiment, the authentication system <b>10</b> performs “device registration process”, “session update process”, “PKI-based mutual authentication to shared key creation”, “shared-key-using mutual authentication to session-related information creation”, “device history information transmission process”, and “control information transmission process” as in the second embodiment.

Device Registration Process

0336The controller and a device perform the processes of making a connection request, PKI-based mutual authentication to shared key creation, shared-key-using mutual authentication to session-related information creation, and registration of the controller and device by performing the process from step S<b>101</b> to step S<b>107</b> in the sequence chart in <figref idref="DRAWINGS">FIG. 12</figref> as in the second embodiment.

0337However, when the authentication processing unit <b>204</b> of the device <b>200</b><i>a </i>performs registration in the connecting controller management table <b>3100</b> via the device management unit <b>201</b> in step S<b>104</b>, information about the group key created in step S<b>103</b> is registered as the item of the group key (current) <b>3140</b> (step S<b>104</b>).

0338When the device management unit <b>101</b> of the controller <b>100</b> performs registration in the connecting device management table <b>3000</b> in step S<b>106</b>, information about the group key is similarly registered as the item of the group key (current) <b>3040</b> (step S<b>106</b>).

Session Update Process

0339<figref idref="DRAWINGS">FIG. 30</figref> and <figref idref="DRAWINGS">FIG. 31</figref> are flowcharts illustrating examples of procedures of session update processes respectively performed by a device and the controller in this embodiment. <figref idref="DRAWINGS">FIG. 32</figref> is a sequence chart illustrating an example of a procedure of the session update process that includes interaction between a device and the controller.

0340The processes respectively performed by a device and the controller are outlined with reference to the flowcharts in <figref idref="DRAWINGS">FIG. 30</figref> and <figref idref="DRAWINGS">FIG. 31</figref>, and thereafter the process including interaction between a device and the controller is described in detail with reference to the sequence chart in <figref idref="DRAWINGS">FIG. 32</figref>.

0341First, the session update process performed by a device is outlined with reference to the flowchart in <figref idref="DRAWINGS">FIG. 30</figref>.

0342A device monitors the remaining session time set with the controller and determines whether the remaining session time is equal to or smaller than a specific value determined in advance (step S<b>4010</b>). If the remaining session time is larger than the specific value (No in step S<b>4010</b>), the device continues monitoring.

0343If the remaining session time is smaller than the specific value determined in advance (Yes in step S<b>4010</b>), the device transmits a session update request to the controller in order to perform a session update (step S<b>4020</b>).

0344The device performs the subroutine “shared-key-using mutual authentication to session-related information creation” to thereby perform mutual authentication with the controller using the shared key, thereafter create a group key and a session key, and set the session validity period, the group key, session key, and session validity period being session-related information (step S<b>4030</b>).

0345If the return value from the subroutine in step S<b>4030</b> is “successful” (Yes in step S<b>4040</b>), the flow proceeds to step S<b>4050</b>. The device registers the information related to a new session which has been created in step S<b>4030</b> as session update information (step S<b>4050</b>).

0346The device waits for a group key update notification from the controller (step S<b>4060</b>). If the device has not received a group key update notification (No in step S<b>4060</b>), the device continues waiting until the device receives a group key update notification.

0347If the device has received a group key update notification (Yes in step S<b>4060</b>), the device replaces the group key that is currently used with the group key newly created in step S<b>4030</b> to thereby perform a group key update (step S<b>4070</b>).

0348On the other hand, if the return value from the subroutine in step S<b>4030</b> is “error” (No in step S<b>4040</b>), the device does not perform a session update and ends the session update process.

0349Next, the session update process performed by the controller is outlined with reference to the flowchart in <figref idref="DRAWINGS">FIG. 31</figref>.

0350The controller waits for a session update request from a device (step S<b>4110</b>). If the controller has not received a session update request (No in step S<b>4110</b>), the controller continues waiting for a session update request from a device.

0351If the controller has received a session update request from a device (Yes in step S<b>4110</b>), the controller performs the subroutine “shared-key-using mutual authentication to session-related information creation” to thereby perform mutual authentication with the device using the shared key, thereafter create a group key and a session key, and set the session validity period, the group key, session key, and session validity period being session-related information (step S<b>4120</b>).

0352If the return value from the subroutine in step S<b>4120</b> is “successful” (Yes in step S<b>4130</b>), the controller registers the information related to a new session which has been created in step S<b>4120</b> as session update information (step S<b>4140</b>).

0353On the other hand, if the return value from the subroutine in step S<b>4120</b> is “error” (No in step S<b>4130</b>), the controller does not perform a session update for the device that is performing a session update.

0354If another device that has not performed a session update is present (Yes in step S<b>4150</b>), the flow returns to the first step, and the controller waits for a session update request from the device that has not performed a session update (step S<b>4110</b>).

0355If the session update process has been completed for all devices (No in step S<b>4150</b>), the controller transmits a group key update notification to devices using the same group key (step S<b>4160</b>).

0356The controller replaces the group key that is currently used with the group key newly created in step S<b>4120</b> to thereby perform a group key update (step S<b>4170</b>).

0357Hereinafter, the process including interaction between devices and the controller will be described with reference to the sequence chart in <figref idref="DRAWINGS">FIG. 32</figref> while differences from the second embodiment are focused. Regarding the devices, it is assumed that the device <b>200</b><i>a </i>is the reference device and the device <b>200</b><i>b </i>is a device other than the reference device, for example.

0358In this embodiment, each device requests a session update to the controller in accordance with the remaining session time as in the second embodiment and performs the process of shared-key-using mutual authentication to session-related information creation. The device and the controller each register session update information.

0359In steps S<b>304</b> and S<b>310</b>, the device management unit <b>201</b> of each device registers the created session key, group key, and session validity period in the connecting controller management table <b>3100</b> stored in the device information storage unit <b>203</b>. At this time, information about the created group key is registered as the item of the group key (new) <b>3150</b>.

0360In steps S<b>305</b> and S<b>309</b>, the device management unit <b>101</b> of the controller registers the created session key, group key, and session validity period in the connecting device management table <b>3000</b> included in the device information storage unit <b>102</b>. At this time, information about the created group key is registered as the item of the group key (new) <b>3050</b>. Regarding the session update state <b>3080</b>, the value of the session update state <b>3080</b> of a device other than the reference device is set to “not updated” as in the above-described embodiments upon a session update with the reference device. Upon a session update with a device other than the reference device, the value of the session update state <b>3080</b> of a device other than the reference device is updated to “updated”.

0361The device management unit <b>101</b> of the controller <b>100</b> refers to the item of the session update state <b>3080</b> in the connecting device management table <b>3000</b> and checks if a “not updated” device is present. At this time, if a device having the item of the session update state being set to “not updated” is present, the controller waits for a session update request from the device. If a device having the session update state being set to “not updated” is not present, the device management unit <b>101</b> of the controller transmits a group key update notification to all devices with which encrypted communication is performed using the same group key (step S<b>311</b>).

0362When the device management unit <b>201</b> of the device has received the group key update notification, the device management unit <b>201</b> updates the group key (current) <b>3140</b> by overwriting the value of the group key (current) <b>3140</b> with the value set in the group key (new) <b>3150</b> in the connecting controller management table <b>3100</b> and deletes the value set in the group key (new) <b>3150</b>.

0363Similarly, the device management unit <b>101</b> of the controller <b>100</b> updates the group key (current) <b>3040</b> by overwriting the value of the group key (current) <b>3040</b> with the value set in the group key (new) <b>3050</b> in the connecting device management table <b>3000</b> and deletes the value set in the group key (new) <b>3050</b>.

0364The processes “PKI-based mutual authentication to shared key creation”, “shared-key-using mutual authentication to session-related information creation”, “device history information transmission process”, and “control information transmission process” are similar to those in the second embodiment, and therefore, description thereof will be omitted.

0365Here, information to be simultaneously transmitted to the devices by the controller is encrypted by using the encryption key that is retained by the controller and the devices as the “group key (current)”.

3-4. Conclusion

0366In the authentication system according to this embodiment, a group key newly created in a session update process performed by the controller and each device is retained in a place other than that of a group key used in encrypted communication. At the time when a session update process is completed by the controller and all devices that are connected to the controller, the controller sends a group key update notification to the devices, and the controller and the devices perform group key switching. As a result, the controller and a plurality of devices can perform a group key update at the same timing, and even if the controller and the devices perform mutual authentication and a group key update, the controller can simultaneously transmit encrypted information to the devices.

4. Modifications

0367The authentication system using the authentication method according to the present disclosure, which has been described with reference to the embodiments, can be modified as follows. The present disclosure is not limited to the authentication method described in the above embodiments as a matter of course.

0368(1) In the above embodiments, the controller and the devices are connected to one network. The network may be a home area network or another type of area network.

0369(2) In the above embodiments, although one group key is set for one controller, a plurality of group keys may be set. In this case, one reference device is set per devices using the same group key.

0370(3) In the above embodiments, in a case where a connection between the controller and the reference device is lost, the controller extracts another device from the connecting device management table stored in the device information storage unit and sets the device as the reference device. In this case, as the reference device, a device that is always turned on may be specified. For example, a device that is always turned on and operates, such as a refrigerator, may be specified.

0371(4) In mutual authentication using a shared key in the above embodiments, challenge-response authentication using a shared key and random numbers is performed; however, the authentication scheme to be used is not limited to this. For example, an authentication scheme based on RFC 5191 Protocol for Carrying Authentication for Network Access (PANA) may be used. A general technique of RFC 5191 described in D. Forsberg and four others, RFC 5191, “Protocol for Carrying Authentication for Network Access (PANA)”, [online], May 2008, Internet Engineering Task Force, [searched on Jun. 24, 2014], Internet <URL: http://www.rfc-editor.org/rfc/pdfrfc/rfc5191.bd.pdf> is used, and therefore, description of the authentication scheme will be omitted.

0372In a case of using RFC 5191, authentication may be performed by further using an EAP-PSK. A session key may be derived by using an EMSK that is derived as a result of a negotiation for an EAP-PSK. Further, as a key deriving function used at this time, HMAC#SHA2#256 may be used.

0373(5) In the above embodiments, the controller creates a group key upon device registration processing and session update processing and delivers the group key to the devices. However, the manner of sharing a group key is not limited to this, and a group key may be shared by performing a key exchange based on ECDH or DH (Diffie-Hellman) between the controller and the reference device.

0374Each of the controller and the reference device may generate random numbers, encrypt the generated random numbers using the shared key, and transmit the result to the counterpart. The counterpart may decrypt the received encrypted random numbers using the shared key, perform an exclusive-OR operation on the random numbers created by itself and the decrypted random numbers, and use the result as a group key.

0375Such procedure may be used as a session key creation procedure that is performed by the controller and each device.

0376(6) The controller according to the present disclosure may be a dedicated device that is used as the controller only, a distribution switchboard installed in a home, a television or another AV device, a home electrical appliance, or the like.

0377(7) The controller may have a function of displaying the amount of power consumption of a connected device, the amount of power of a storage battery, and the amount of power generated from photovoltaic generation.

0378(8) A communication scheme used by the controller and the devices according to the present disclosure may be based on Ethernet (registered trademark), Wi-Fi (Wireless Fidelity), specified lower power radio, power line communication, or Bluetooth (registered trademark).

0379(9) In the first embodiment above, in the session update process, in a case where a device that has not performed a session update is present, a session update notification is transmitted to the device to thereby make the device start a session update. Here, in a case where the device is not turned on, the controller may transmit a session update notification to the device at regular intervals.

0380(10) In the first embodiment above, in the session update process, in a case where a device that has not performed a session update is present, a session update notification is transmitted to the device to thereby make the device start a session update. Here, in a case where it is determined that the device is unable to start a session update process because the device is performing a process, for example, the device may communicate the delay time of the session update to the controller and perform the session update process after the elapse of the delay time.

0381(11) In the above embodiments, the validity period of a session is managed by using the remaining session time stored in the connecting device management table or the connecting controller management table. However, the manner of managing the validity period is not limited to this, and the validity period may be managed by using the session start date and time or the session end date and time. For example, in a case of management using the session start date and time, a specific session validity period may be set in advance, a date and time obtained by adding the session validity period to the session start date and time may be compared with the current date and time, and determination as to whether the session is to be updated may be performed. Alternatively, in a case of management using the session end date and time, for example, the current date and time may be compared with the session end date and time, and determination as to whether the session is to be updated may be performed.

0382(12) In the above embodiments, in the session update process, the device determines the timing of a session update on the basis of the remaining session time and transmits a session update request to the controller to thereby start the session update. However, the manner of starting a session update is not limited to this, and the controller may determine the timing of a session update on the basis of the remaining session time and start the session update.

0383(13) In the above embodiments, a session key for performing one-to-one encrypted unicast communication is shared between a device and the controller. However, a session key need not be shared, and entire encrypted communication between a device and the controller may be performed by using a group key.

0384(14) In the above embodiments, in the session update process, both the group key and the session key are updated. However, the session update process is not limited to this, and only the group key or only the session key may be updated upon session update processing.

0385(15) The controller, the devices, and the server, which are apparatuses related to the authentication system in the above embodiments, may each be constituted by a processor, memory, and so on specifically. To the memory, a computer program is recorded. The processor operates in accordance with the computer program recorded to the memory to thereby enable each apparatus to implement its function. Here, the computer program is constituted by a combination of a plurality of instruction codes indicating instructions given to the computer in order to implement predetermined functions.

0386(16) Some or all of the constituent elements that constitute each apparatus related to the authentication system in the above embodiments may be constituted by one system LSI (Large Scale Integration circuit). Each of the constituent elements that constitute each apparatus described above may be implemented as one chip, or some or all of the constituent elements may be included in one chip.

0387Although a system LSI is mentioned here, the system LSI may be called an IC (Integrated Circuit), an LSI, a super LSI, or an ultra LSI depending on the difference in the degree of integration. Further, the technique for circuit integration is not limited to LSI, and circuit integration may be implemented by using a dedicated circuit or a general-purpose processor. An FPGA (Field Programmable Gate Array) that can be programmable after manufacturing the LSI, or a reconfigurable processor for which connections and settings of circuit cells within the LSI can be reconfigurable may be used.

0388In a case where a technique for circuit integration that replaces LSI emerges with the advancement of semiconductor technology or on the basis of any technology that is separately derived, the functional blocks may be integrated by using the technique as a matter of course. Application of biotechnology is possible, for example.

0389(17) Some or all of the constituent elements that constitute each apparatus related to the authentication system in the above embodiments may be formed of an IC card or a standalone module that can be attached to and detached from the apparatus. The IC card or the module may be tamper-resistant.

0390(18) The present disclosure may be the method described above. The present disclosure may be a computer program that causes a computer to implement the method or may be a digital signal that includes the computer program. The computer program may be stored in a memory and executed by a processor.

0391The present disclosure may be a computer-readable recording medium, such as a flexible disk, a hard disk, a CD-ROM, an MO, a DVD, a DVD-ROM, a DVD-RAM, a BD (Blu-ray (registered trade mark) Disc), or a semiconductor memory, for example, to which the computer program or the digital signal is recorded. The present disclosure may be the digital signal that is recorded to such a recording medium.

0392The present disclosure may be the computer program or the digital signal that is transmitted via a telecommunication line, a wireless or wired communication line, a network, typically, the Internet, data broadcasting, or the like.

0393The present disclosure may be a computer system that includes a processor and a memory, in which the computer program may be recorded to the memory and the processor may operate in accordance with the computer program.

0394The present disclosure may be implemented as another independent computer system by transferring the computer program or the digital signal, which is recorded to the recording medium, or by transferring the computer program or the digital signal via the network or the like.

0395(19) The present disclosure may be implemented by partially combining the above-described embodiments or modifications.

5. Supplementary Notes

0396Hereinafter, one embodiment of the authentication method related to the present disclosure and effects thereof will be further described.

0397(a) An authentication method according to the present disclosure is an authentication method performed in an authentication system including a controller, a first device, and a second device. The authentication method includes: a first step comprising: performing mutual authentication between the controller and the first device, creating a group key, sharing the group key between the controller and the first device, and setting the first device as a reference device; a second step comprising: performing mutual authentication between the controller and the second device, and sharing the group key with the second device; a third step performed after the second step comprising: performing mutual authentication between the controller and the first device, updating the group key, and sharing the updated group key between the controller and the first device; and a fourth step performed at a group key update timing when the group key is updated comprising: performing mutual authentication between the controller and the second device, and sharing the updated group key with the second device also.

0398Accordingly, a device among the devices connected to the controller is set as a reference device, and devices other than the reference device perform a group key update at the timing of a group key update by the reference device to thereby enable a plurality of devices to perform a group key update at the same timing. Even if the controller and the devices perform mutual authentication and a group key update, the controller can simultaneously transmit encrypted information to the devices.

0399(b) In the authentication method according to (a) above, the controller, the first device, and the second device may be connected to one home area network.

0400Accordingly, the controller and the devices that are connected to a home area network can perform a group key update at the same timing. Even if the controller and the devices perform mutual authentication and a group key update, the controller can simultaneously transmit encrypted information to the devices.

0401(c) The authentication method according to (a) above may further include transmitting, when the group key is updated, a group key update notification to the second device. The group key update timing may be a timing when the second device receives the group key update notification.

0402Accordingly, after a group key update by the controller and the reference device, a device that does not share the updated group key receives a group key update notification from the controller and updates the group key to thereby enable a plurality of devices connected to the controller to perform a group key update at the same timing.

0403(d) In the authentication method according to (a) above, the first step further include setting a first session period between the controller and the first device; the second step further include setting, between the controller and the second device, a second session period that is based on the first session period and on a period elapsed from a time point of setting the first session period; the third step may be started in accordance with the first session period and the period elapsed from the time point of setting the first session period; and the group key update timing may be a timing that is based on the second session period and a period elapsed from a time point of setting the second session period.

0404Accordingly, the session period for the controller and a device other than the reference device is set on the basis of the remaining session period for the controller and the reference device, and the controller and each device connected to the controller perform a group key update on the basis of the session period to thereby enable a plurality of devices connected to the controller to perform a group key update at the same timing.

0405(e) In the authentication method according to (a) above, the controller may own a private key and a public key certificate of the controller; the first device may own a private key and a public key certificate of the first device; the authentication method may further include creating a first shared key and sharing the first shard key between the controller and the first device; the mutual authentication performed in the first step may be public key authentication in which mutual authentication is performed by using the public key certificate owned by the controller and the public key certificate owned by the first device in accordance with a public key infrastructure; and the mutual authentication performed in the third step may be shared key authentication in which mutual authentication is performed by using the first shared key.

0406Here, in a case of making a connection between the controller and a device, for example, mutual authentication using a public key certificate based on a PKI is performed. In a case of subsequent session update processing, mutual authentication using a shared key is performed. In general, mutual authentication using a shared key involves a lower processing load compared to mutual authentication based on a PKI. Accordingly, by employing a procedure using a shared key, a processing load related to mutual authentication can be reduced.

0407(f) In the authentication method according to (e) above, in the creating and sharing of the first shared key, the first shared key may be shared through a key exchange; and the shared key authentication may be challenge-response authentication in which random numbers and the first shared key are used.

0408Accordingly, the controller and a device can mutually confirm their validity by performing challenge-response authentication using a shared key and random numbers.

0409(g) In the authentication method according to (e) above, the second device may own a private key and a public key certificate of the second device; the authentication method may further include creating a second shared key and sharing the second shared key between the controller and the second device; the mutual authentication performed in the second step may be public key authentication in which mutual authentication is performed by using the public key certificate owned by the controller and the public key certificate owned by the second device in accordance with a public key infrastructure; and the mutual authentication performed in the fourth step may be shared key authentication in which mutual authentication is performed by using the second shared key.

0410Accordingly, the controller combines and performs two types of procedures, namely, mutual authentication based on a PKI and mutual authentication using a shared key with devices connected to the controller to thereby reduce a processing load related to mutual authentication.

0411(h) An authentication system according to the present disclosure is an authentication system including a controller, a first device, and a second device. The authentication system includes: a first mutual authenticator that performs mutual authentication between the controller and the first device, creates a group key, shares the group key between the controller and the first device, and sets the first device as a reference device; a second mutual authenticator that performs mutual authentication between the controller and the second device, and shares the group key with the second device; a third mutual authenticator that performs mutual authentication between the controller and the first device, updates the group key, and shares the updated group key between the controller and the first device; and a fourth mutual authenticator that, at a group key update timing when the group key is updated, updates the group key, performs mutual authentication between the controller and the second device, and shares the updated group key with the second device.

0412Accordingly, a device among the devices connected to the controller is set as a reference device, and devices other than the reference device perform a group key update at the timing of a group key update by the reference device to thereby enable a plurality of devices to perform a group key update at the same timing. Even if the controller and the devices perform mutual authentication and a group key update, the controller can simultaneously transmit encrypted information to the devices.

0413The authentication method according to the present disclosure can be used in a network system in which a controller simultaneously transmits information encrypted using a group key to a plurality of connected devices for mutual authentication, a group key update, and the like performed by the controller and the devices.