WO2016181586A1 - 認証方法及び認証システム - Google Patents

認証方法及び認証システム Download PDF

Info

Publication number
WO2016181586A1
WO2016181586A1 PCT/JP2016/000946 JP2016000946W WO2016181586A1 WO 2016181586 A1 WO2016181586 A1 WO 2016181586A1 JP 2016000946 W JP2016000946 W JP 2016000946W WO 2016181586 A1 WO2016181586 A1 WO 2016181586A1
Authority
WO
WIPO (PCT)
Prior art keywords
controller
session
group key
key
mutual authentication
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/JP2016/000946
Other languages
English (en)
French (fr)
Inventor
勇二 海上
前田　学
松島　秀樹
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Panasonic Intellectual Property Corp of America
Original Assignee
Panasonic Intellectual Property Corp of America
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Panasonic Intellectual Property Corp of America filed Critical Panasonic Intellectual Property Corp of America
Priority to EP16792321.8A priority Critical patent/EP3297207A1/en
Priority to CN201680001228.XA priority patent/CN106416122A/zh
Priority to JP2017517588A priority patent/JPWO2016181586A1/ja
Publication of WO2016181586A1 publication Critical patent/WO2016181586A1/ja
Priority to US15/391,901 priority patent/US20170111357A1/en
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/44—Program or device authentication
    • G06F21/445—Program or device authentication by mutual authentication, e.g. between devices or programs
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0869—Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0618—Block ciphers, i.e. encrypting groups of characters of a plain text message using fixed encryption transformation
    • H04L9/0631—Substitution permutation network [SPN], i.e. cipher composed of a number of stages or rounds each involving linear and nonlinear transformations, e.g. AES algorithms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0618—Block ciphers, i.e. encrypting groups of characters of a plain text message using fixed encryption transformation
    • H04L9/0637—Modes of operation, e.g. cipher block chaining [CBC], electronic codebook [ECB] or Galois/counter mode [GCM]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/083—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP]
    • H04L9/0833—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP] involving conference or group key
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0891—Revocation or update of secret information, e.g. encryption key update or rekeying
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3242—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving keyed hash functions, e.g. message authentication codes [MACs], CBC-MAC or HMAC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3271—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
    • H04L9/3273—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response for mutual authentication
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2107—File encryption
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2151—Time stamp

Definitions

  • This disclosure relates to a technique for authenticating a device connected to an area network, and more particularly, to a technique for performing mutual authentication between a controller and a device and updating a group key.
  • a network formed by connecting devices installed in a home is hereinafter referred to as a home area network.
  • a specific device (hereinafter referred to as a “controller”) is connected to such a home area network, and communication between the device and an external server is performed via the controller. Therefore, it is required to control communication in the home by safely setting the connection between the controller and each device, and to prevent information leakage due to connection due to impersonation of unauthorized devices or interception of communication contents. For example, measures such as authentication of connected devices for the former and communication encryption for the latter are conceivable.
  • the controller and the device that have been authenticated for validity share an encryption key and use the encryption key. Perform encrypted communication.
  • the controller and the device share the same encryption key (hereinafter referred to as a “group key”), so that the controller transmits the same information to multiple devices simultaneously. Multicast communication and broadcast communication encryption are performed.
  • the controller, the first device, and the second device share a group key, and the controller performs broadcast transmission of the information encrypted using the group key to the first device and the second device.
  • an authentication method between the controller and the first device and the second device, wherein the controller and the first device perform mutual authentication, create and share a group key A first mutual authentication step for setting the first device as a reference device, the controller and the second device perform mutual authentication, and the group key created in the first mutual authentication step is also stored in the second device.
  • the controller and the first device as the reference device perform mutual authentication again, In the third mutual authentication step of updating the loop key and sharing the updated group key, and in the group key update timing at which the controller and the reference device update the group key, the controller and the reference device are not
  • the MAC is generated from the transmission data, the header, the transmission source address, and the transmission destination address, and the encrypted data, the header, the transmission source address, the transmission destination address, and the MAC are generated.
  • An encryption step for performing the simultaneous broadcast of the message including the message.
  • FIG. 1 is a schematic diagram showing a system configuration of the authentication system 10.
  • FIG. 2 is a functional block diagram of the main part of the controller 100.
  • FIG. 3 is a diagram illustrating an example of the data structure and data of the connected device management table 1000.
  • FIG. 4 is a diagram illustrating an example of the data configuration of the public key certificate.
  • FIG. 5 is a diagram illustrating an example of a data structure of the CRL.
  • FIG. 6 is a functional block diagram of the main part of the device 200a.
  • FIG. 7 is a diagram illustrating an example of the data structure and data of the connection controller management table 1100.
  • FIG. 8 is a functional block diagram of the main part of the server 300.
  • FIG. 9 is a diagram illustrating an example of the data structure and data of the device information management table 1300.
  • FIG. 10 is a flowchart illustrating an example of a procedure of device registration processing in the device.
  • FIG. 11 is a flowchart illustrating an example of a procedure of device registration processing in the controller.
  • FIG. 12 is a sequence diagram illustrating an example of the procedure of the device registration process.
  • FIG. 13 is a flowchart illustrating an example of a procedure of session update processing in the device.
  • FIG. 14 is a flowchart illustrating an example of a procedure of session update processing in the controller.
  • FIG. 15 is a sequence diagram illustrating an example of a procedure for session update processing.
  • FIG. 16 is a flowchart showing an example of a procedure for mutual authentication to shared key creation based on PKI in a device.
  • FIG. 17 is a flowchart showing an example of a procedure for mutual authentication to shared key creation based on PKI in the controller.
  • FIG. 18 is a sequence diagram showing an example of a procedure for mutual authentication to shared key creation based on PKI.
  • FIG. 19 is a flowchart showing an example of a procedure for creating information related to mutual authentication to a session using a shared key in a device.
  • FIG. 20 is a flowchart illustrating an example of a procedure for creating information related to mutual authentication to a session using a shared key in the controller.
  • FIG. 21 is a sequence diagram illustrating an example of a procedure for creating information related to mutual authentication to a session using a shared key.
  • FIG. 22 is a sequence diagram illustrating an example of a procedure of device history information transmission processing.
  • FIG. 23 is a sequence diagram illustrating an example of the procedure of the control information transmission process.
  • FIG. 24 is a data configuration diagram of message formats before and after encryption.
  • FIG. 25 is a sequence diagram illustrating an example of a procedure of device history information MAC transmission processing.
  • FIG. 26 is a sequence diagram showing an example of the procedure of the control information MAC transmission process.
  • FIG. 27 is a diagram illustrating an example of the data structure and data of the connected device management table 2000 according to the second embodiment.
  • FIG. 28 is a flowchart illustrating an example of a procedure of session update processing in the device according to the second embodiment.
  • FIG. 29 is a flowchart illustrating an example of a procedure of session update processing in the controller according to the second embodiment.
  • FIG. 30 is a sequence diagram illustrating an example of a procedure for session update processing according to the second embodiment.
  • FIG. 31 is a diagram showing an example of the data structure and data of the connected device management table 3000 according to the third embodiment.
  • FIG. 32 is a diagram illustrating an example of the data structure and data of the connection controller management table 3100 according to the third embodiment.
  • FIG. 33 is a flowchart illustrating an example of a procedure of session update processing in the device according to the third embodiment.
  • FIG. 34 is a flowchart illustrating an example of a procedure of session update processing in the controller according to the third embodiment.
  • FIG. 35 is a sequence diagram illustrating an example of a procedure for session update processing according to the third embodiment.
  • each device updates the group key at each timing, each device holds a different group key. For example, if one device holds the updated group key, but the second device holds the pre-update group key, the controller will broadcast the encrypted information using the group key. I can't do it.
  • the present disclosure has been made in view of the related problems, and provides an authentication method capable of matching the update timing of the group key between each device and the controller.
  • the authentication method sets a reference device from devices connected to a controller, and based on the timing of group key update in the reference device, another device updates the group key. It becomes possible to synchronize the group key update timing among a plurality of devices.
  • the controller can perform simultaneous transmission of encrypted information.
  • an authentication system 10 as an embodiment using the authentication method according to the present disclosure will be described with reference to the drawings.
  • FIG. 1 is a schematic diagram illustrating an example of a system configuration of an authentication system 10 according to the present embodiment.
  • the authentication system 10 includes a controller 100 and devices 200a, 200b, 200c connected to the home area network 400.
  • the controller 100 in the authentication system 10 connects to the server 300 via a network 500 that is a communication network such as the Internet.
  • the controller 100 and the devices 200a to 200c are connected to one home area network 400. Although not shown in the figure, they may be connected via a network device (for example, a hub, a router, etc.). The place where the controller 100 or each device is installed may be indoors or outdoors.
  • a network device for example, a hub, a router, etc.
  • the controller 100 and each of the devices 200a to 200c perform mutual authentication when starting connection. If mutual authentication confirms the validity of each other, the encryption key is shared and encrypted communication is performed. Thereafter, the controller and each device perform session update processing at their respective predetermined timings, perform mutual authentication at each session update processing, update the encryption key if the result is valid, and continue encryption communication To do.
  • Such a controller 100 and each device share three types of shared keys after confirming each other's validity in mutual authentication at the time of connection.
  • the one shared key is a shared key used for mutual authentication during the session update process between the controller 100 and each device.
  • a controller and a device are connected, first, mutual authentication based on a public key authentication infrastructure (PKI: Public Key Infrastructure) is performed.
  • PKI Public Key Infrastructure
  • the mutual authentication performed by the controller and the device is performed using the one shared key.
  • shared key when simply described as “shared key”, the shared key used for the mutual authentication is indicated. However, it is obviously excluded when a description showing a group key and a session key described below is given.
  • the controller and the device share a shared key.
  • the second shared key and the third shared key are shared keys used for this encryption communication, and are called a group key and a session key, respectively.
  • the group key is an encryption key that is used by the controller to simultaneously transmit the same information to a plurality of devices, and the controller shares the same group key with all the devices connected to the controller.
  • the session key is an encryption key that is used for one-to-one unicast communication between the controller and each device. The controller shares an individual encryption key with each device.
  • a session valid period is provided for communication between the controller and each device, and the group key and the session key can be used during the session valid period. After the session is set, if the session valid period is exceeded, control is performed so that the group key and the session key cannot be used. In order to continue encrypted communication even after the session validity period has elapsed, it is necessary to perform session update processing between the controller and each device, create a new group key and session key, and set a new session. There is.
  • the controller sets one of the connected devices as a reference device.
  • the timing at which the controller 100 and each device update the group key is based on the timing at which the reference device performs session update processing and updates the group key, and a specific method will be described later.
  • the reference device is, for example, a device to which the controller 100 is connected first.
  • the server 300 is an external server that provides services to the devices 200a to 200c.
  • the server 300 and each device communicate with each other via the controller 100.
  • each device transmits device history information indicating the operation of the device to the server 300 via the controller 100.
  • the server 300 transmits service information to each device via the controller 100.
  • the server 300 transmits control request information for causing each device to execute a predetermined function.
  • the controller 100 receives and decodes the control request information, and creates and transmits a control command for causing each device to execute it.
  • Each device that has received the control command executes the function requested by the server 300.
  • Controller 100> 2 is a functional block diagram of the main part of the controller 100.
  • the controller 100 includes a device management unit 101, a device information holding unit 102, an authentication processing unit 103, an authentication information holding unit 104, and a communication unit 105.
  • the controller 100 includes a processor and a memory (not shown), and functions of the device management unit 101, the device information holding unit 102, the authentication processing unit 103, the authentication information holding unit 104, and the communication unit 105. Is realized by the processor executing a program stored in the memory. Retention of each data in the device information retaining unit 102 and the authentication information retaining unit 104 is realized by a memory.
  • the device management unit 101 has the following functions in order to control the connection between the controller 100 and the devices 200a to 200c.
  • the device management unit 101 accepts connection requests and session update requests from devices to the controller 100 via the communication unit 105. Then, the authentication processing unit 103 is caused to execute mutual authentication processing with the device.
  • the device management unit 101 stores the connected device management data in the connected device management table 1000 held by the device information holding unit 102. sign up. Details of the connected device management data stored in the connected device management table 1000 will be described later.
  • the device management unit 101 sets a reference device.
  • the first device connected to the controller 100 may be set as the reference device.
  • another device is extracted from the connected device management table 1000 held by the device information holding unit 102 and set as the reference device.
  • a device whose power is always on may be set as a reference device.
  • the device management unit 101 also registers the setting of the reference device in the connected device management table 1000.
  • the authentication processing unit 103 determines whether or not to set the device as a reference device, and the device management unit 101 registers in the connected device management table 1000 in response to the determination result. .
  • the device management unit 101 refers to the session update state, which is an item in the connected device management table 1000, and notifies the device whose session has not been updated via the communication unit 105.
  • the session update notification is for prompting the device to update the session, and thereafter, the session is updated by receiving a session update request from the device to the controller 100 again.
  • the device management unit 101 refers to the value of the remaining session time, which is an item of the connected device management table 1000, for a device that has exceeded the session valid period without being updated, that is, for a device whose remaining session time is zero.
  • the encryption communication with the device is prohibited by deleting the information of the encryption key such as the group key and the session key held with the device.
  • the device management unit 101 decrypts the encrypted device history information received from the devices 200a to 200c via the communication unit 105.
  • the decrypted device history information is transmitted to the server 300 via the communication unit 105.
  • the device management unit 101 processes the device control request information received from the server 300 via the communication unit 105 into a format that can be instructed to the device, and then encrypts the information using the group key or session key.
  • the data is transmitted to the device via 105.
  • the device information holding unit 102 holds information on the devices 200 a to 200 c connected to the controller 100.
  • FIG. 3 is a diagram illustrating an example of the data structure and data of the connected device management table 1000 that the device information holding unit 102 holds to manage device information.
  • the connected device management table 1000 includes a connected device management record group for each device.
  • the connected device management record is data to be registered when the device is recognized as a valid device in the device registration process performed when the device and the controller are connected, and includes a device ID 1010, a certificate ID 1020, and a shared key 1030.
  • Group key 1040, session key 1050, remaining session time 1060, session update status 1070, and reference device 1080 are included.
  • the device ID 1010 is an identifier that uniquely determines the device.
  • Certificate ID 1020 is the certificate ID of the public key certificate of the device.
  • the shared key 1030 is shared key data shared between the controller 100 and the device.
  • the group key 1040 is group key data used for encrypting information that the controller 100 transmits to a plurality of devices simultaneously.
  • FIG. 3 shows that the same group key “11223...” Is shared with the device ID 1 to device ID 3 which are all devices connected to the controller.
  • the example in FIG. 3 shows an example in which the device ID 1 to device ID 3 share one item field of the group key, but each device ID has an individual item column, and when the item is registered
  • devices other than the reference device may set the same group key data as the reference device.
  • the session key 1050 is session key data used for encrypting unicast communication between the controller 100 and the device.
  • the controller indicates that different session keys are shared with each of the devices ID1 to ID3.
  • the session remaining time 1060 is a remaining period of the session valid period set between the controller 100 and the device.
  • a predetermined predetermined session valid period is provided between the controller 100 and the device.
  • the session valid period is registered as the remaining session time 1060. Thereafter, the remaining session time 1060 represents the remaining period of the session valid period by counting down the value of the item as time passes.
  • the device management unit 101 deletes the group key and session key information held by the device management unit 101 and the encrypted communication is prohibited for the device for which the remaining session time is zero.
  • the session update state 1070 is data indicating whether or not the device indicated by the device ID has updated the session with the controller 100 in the period after the session update between the controller 100 and the reference device.
  • the session update state 1070 relating to the device other than the reference device is updated to “not updated”. Thereafter, when the controller 100 performs a session update process with the device, the session update state 1070 is updated to “updated”.
  • the item of the reference device 1080 is data indicating whether or not the device is a reference device.
  • the example of FIG. 3 indicates that the device with the device ID 1 is the reference device.
  • the controller has already updated the session with the device with the device ID 2 and no session with the device with the device ID 3. Indicates that this is an update.
  • the authentication processing unit 103 has a function of performing mutual authentication processing with a device connected to the controller 100.
  • Mutual authentication based on PKI is performed at the time of connection with the device, and mutual authentication by challenge response authentication using a shared key and a random number is performed at the time of session update.
  • the authentication processing unit 103 receives the device public key certificate from the device management unit 101 together with the device authentication request, and performs authentication processing based on the PKI. Specifically, first, based on CRL (Certificate Revocation List) stored in the authentication information holding unit 104, it is confirmed that the certificate ID related to the public key certificate of the acquired device is not described in the CRL. . Then, the signature attached to the public key certificate is verified using the public key of the certificate authority.
  • the certificate authority is the server 300.
  • the authentication processing unit 103 performs challenge response authentication, which is mutual authentication using a shared key, when updating a session between the controller 100 and the device.
  • the authentication processing unit 103 also has a function of creating the shared key by exchanging keys with the device.
  • the authentication processing unit 103 generates a random number and transmits it to the device via the communication unit 105. Then, the random number encrypted by the device with the shared key and returned is decrypted with the shared key held by the controller, and the validity of the device is confirmed by comparing with the random number created by itself.
  • the authentication processing unit 103 encrypts the random number received from the device with the shared key and returns it, so that verification on the device side is also performed.
  • the authentication processing unit 103 has a function of executing processing necessary for session setting and updating. Specifically, a group key and a session key, which are shared keys for encrypting communication between the controller 100 and the device, are created. In addition, a session valid period is set, and the session key and group key are registered in the connected device management table 1000 held by the device information holding unit 102 via the device management unit 101.
  • the authentication information holding unit 104 holds the controller 100's own private key and public key certificate.
  • a CRL used for confirming that the public key certificate of the counterpart device has not expired is held.
  • Such a private key, public key certificate, and CRL are embedded when the controller 100 is manufactured.
  • FIG. 4 is a diagram showing a data configuration of a public key certificate 1500 which is a standard data configuration example of a public key certificate.
  • the public key certificate 1500 includes a version 1510 related to the certificate, an issuer 1520, a valid period start 1530, a valid period end 1540, a certificate ID 1550, a public key 1560, and a signature 1570 of the server 300 as the certificate authority. It is a configuration.
  • the public key 1560 is data of the public key of the controller itself
  • the signature 1570 is a signature created and assigned using the private key of the certificate authority.
  • FIG. 5 is a diagram illustrating a CRL 1600 that is a standard data configuration example of the CRL.
  • the CRL 1600 includes a CRL version 1610 related to the CRL, an issuer 1620, an issue date 1630, a next issue date 1640, a revoked certificate ID 1650, and a signature 1660 of a server that is a certificate authority.
  • the revoked certificate ID 1650 is not limited to one ID, and a plurality of revoked certificate IDs may be held.
  • a signature 1660 is a signature created and assigned using the private key of the certificate authority.
  • the communication unit 105 is a communication interface for the controller 100 to connect to each of the devices 200a to 200c and the server 300. For example, it has a function of performing encrypted communication with the devices 200a to 200c using the session key and group key held in the connected device management table 1000 of the device information holding unit 102.
  • the communication unit 105 has a function of performing cryptographic communication with the server 300, and performs, for example, SSL (Secure Socket Layer) communication.
  • SSL Secure Socket Layer
  • the SSL server certificate necessary for SSL communication is held in the communication unit 105.
  • the devices 200a to 200c are home appliances, AV devices, and home equipment that have a function of connecting to a network, and specifically, for example, a television, a recorder, an air conditioner, a refrigerator, and a storage battery.
  • each device has a unique function, and in this respect, if the device is a different type of device, it is not common to other devices.
  • a washing machine is a washing function
  • an air conditioner is a function such as heating or cooling. Since this is a general function, a description thereof will be omitted. Only the function related to the authentication method which is the invention of the present application will be described, and it goes without saying that not only the device 200a but also other devices have the same function.
  • FIG. 6 is a functional block diagram of the main part of the device 200a.
  • the device 200a includes a device management unit 201, a device history holding unit 202, a device information holding unit 203, an authentication processing unit 204, an authentication information holding unit 205, and a communication unit. 206 is included.
  • the device 200a includes a processor and a memory, and includes a device management unit 201, a device history holding unit 202, a device information holding unit 203, an authentication processing unit 204, an authentication information holding unit 205,
  • Each function of the communication unit 206 is realized by the processor executing a program stored in the memory. Retention of each data in the device history holding unit 202, the device information holding unit 203, and the authentication information holding unit 205 is realized by a memory.
  • the device management unit 201 controls connection with the controller 100. Specifically, it has the following functions.
  • the device management unit 201 When connecting to the controller 100, the device management unit 201 transmits a connection request to the controller 100 via the communication unit 206.
  • the device management unit 201 when the device management unit 201 receives the public key certificate of the controller 100 via the communication unit 206, the device management unit 201 causes the authentication processing unit 204 to perform authentication processing based on PKI.
  • the device management unit 201 stores the connection controller data in the connection controller management table 1100 held by the device information holding unit 203. sign up. Details of the connection controller data held in the connection controller management table 1100 will be described later.
  • the device history information related to the device operation history recorded in the device history holding unit 202 is encrypted with the session key and transmitted to the controller 100 via the communication unit 206.
  • the device history information related to the operation of the device is transmitted regularly or irregularly, and transmitted to the server 300 via the controller 100.
  • the device management unit 201 refers to the item of the remaining session time held in the connection controller management table of the device information holding unit 203, and when the value of the remaining session time becomes equal to or less than a predetermined threshold value, Initiate session update.
  • the predetermined threshold is, for example, a value that is 10% of the session valid period or a value that is twice the time required for the session update process.
  • the device management unit 201 receives a session update notification from the controller 100, it starts session update regardless of the value of the remaining session time.
  • the device management unit 201 causes the authentication processing unit 204 to execute processing. Thereafter, the group key, session key, and session validity period created by the authentication processing unit 204 are received and registered in the connection controller management table 1100 held by the device information holding unit 203.
  • the device history holding unit 202 has a function of recording and holding the operation of the device 200a as device history information.
  • the device history holding unit 202 records information indicating these operations as device history information each time the device 200a is operated or a function is executed.
  • the device history information is shown as an example of information transmitted from the device 200a to the server 300 via the controller 100, but is not a main component of the invention of the present application. Omitted.
  • the device information holding unit 203 holds information on the controller 100 connected to the device 200a.
  • FIG. 7 is a diagram illustrating an example of the data structure and data of the connection controller management table 1100 that the device information holding unit 203 holds in order to manage controller information.
  • the connection controller management table 1100 includes a connection controller management record group.
  • the connection controller management record is data to be registered when the controller is recognized as a valid device in the device registration process performed when the device and the controller are connected.
  • the controller ID 1110, the certificate ID 1120, and the shared key 1130 are registered.
  • Group key 1140, session key 1150, and remaining session time 1160 are included.
  • Controller ID 1110 is an identifier that uniquely defines the controller.
  • Certificate ID 1120 is the certificate ID of the controller's public key certificate.
  • the shared key 1130 is shared key data that the device 200a shares with the controller 100.
  • the group key 1140 is data of a shared key used for encrypting information that the controller 100 transmits to the devices all at once. On the device side, the received information is decrypted using the group key.
  • the session key 1150 is shared key data used for performing encrypted unicast communication with the controller 100.
  • the session remaining time 1160 is a remaining period of the session valid period set with the controller 100.
  • a predetermined predetermined session valid period is provided between the device 200a and the controller 100.
  • the session valid period is registered in the session remaining time 1160. Thereafter, the remaining session time 1160 represents the remaining period of the session valid period by counting down the value of the item as time passes.
  • the authentication processing unit 204 has a function of performing mutual authentication processing with the controller 100. At the time of connection with the controller, mutual authentication based on PKI is performed, and at the time of session update, mutual authentication by challenge response authentication using a shared key and a random number is performed.
  • a controller public key certificate is received from the device management unit 201 together with a controller authentication request, and an authentication process based on PKI is performed. Specifically, based on the CRL stored in the authentication information holding unit 205, it is confirmed that the certificate ID of the acquired controller public key certificate is not described in the CRL. Also, the signature of the public key certificate is verified using the public key of the certificate authority.
  • the certificate authority is the server 300.
  • the authentication processing unit 204 performs challenge response authentication, which is mutual authentication using a shared key, when updating a session with the controller 100.
  • the authentication processing unit 204 also has a function of creating the shared key by exchanging keys with the controller 100.
  • the authentication processing unit 204 generates a random number and transmits it to the controller 100 via the communication unit 206. Then, the authentication processing unit 204 confirms the validity of the controller by decrypting the random number encrypted and returned by the controller 100 with the shared key held by the device and collating with the random number created by itself.
  • the authentication processing unit 204 encrypts a random number received from the device with a shared key and returns it, so that verification on the device side is also performed.
  • the authentication processing unit 204 has a function of executing processing necessary for creating and updating a session. Specifically, when the start of the session update process is received from the device management unit 201, a session update request is transmitted to the controller 100 via the communication unit 206. The authentication processing unit 204 receives the updated session key, group key, and session validity period from the controller 100 via the communication unit 206, and the device information holding unit 203 receives the updated session key via the device management unit 201. Registered in the held connection controller management table 1100.
  • the authentication information holding unit 205 holds the private key and public key certificate of the device 200a itself.
  • a CRL used for confirming that the public key certificate has not expired in the mutual authentication based on PKI is held.
  • Such a private key, public key certificate, and CRL are embedded when the device is manufactured.
  • the public key held by the public key certificate of the device 200a is the public key of the device 200a.
  • the communication unit 206 is a communication interface for connecting to the controller 100. For example, it has a function of performing encrypted communication with the controller 100 using a session key and a group key held in the connection controller management table 1100 of the device information holding unit 203.
  • FIG. 8 is a functional block diagram of the main part of the server 300.
  • the server 300 includes a device information management unit 301, a device information holding unit 302, a CRL management unit 303, a CRL holding unit 304, and a communication unit 305.
  • the server 300 has a configuration including a processor and a memory, and each function of the device information management unit 301, the device information holding unit 302, the CRL management unit 303, the CRL holding unit 304, and the communication unit 305 is shown. Is realized by the processor executing a program stored in the memory. Retention of each data in the device information retaining unit 302 and the CRL retaining unit 304 is realized by a memory.
  • the device information management unit 301 has the following functions to control the device information holding unit 302 and manage information on the controller connected to the server 300 including device information connected to the controller.
  • the device information management unit 301 registers the controller and device information received from the controller via the communication unit 305 in the device information management table 1300 held by the device information holding unit 302.
  • the CRL management unit 303 is notified of the certificate ID of the public key certificate of the device.
  • the device information holding unit 302 holds information about controllers and devices connected to the server 300.
  • FIG. 9 is a diagram illustrating an example of the data structure and data of the device information management table 1300 that the device information holding unit 302 has. It is.
  • the device information management table 1300 includes items of a controller ID 1310 and a certificate ID 1320 related to the controller. Further, items of a device ID 1330, a certificate ID 1340, and device history information 1350 related to a device connected to the controller are included. Each item will be described using the example of FIG.
  • Controller ID 1310 is an identifier that uniquely defines the controller.
  • the controller certificate ID 1320 is the certificate ID of the controller public key certificate.
  • the device ID 1330 is a device ID that identifies a device connected to the controller.
  • the controller identified by the controller ID1 indicates that three devices identified by the device ID1, the device ID2, and the device ID3 are connected.
  • the device certificate ID 1340 is the certificate ID of the device public key certificate.
  • the device history information 1350 is device history information data collected from devices.
  • the device history information itself may be held for each device in another table, and the item of the device history information 1350 may hold link information to the other table.
  • CRL management unit 303 When the CRL management unit 303 receives the certificate ID of the public key certificate of the unauthorized device from the device information management unit 301, the CRL management unit 303 issues a CRL.
  • the CRL management unit 303 holds the public key and secret key of the server 300.
  • the CRL management unit 303 When the CRL management unit 303 issues a CRL, the CRL management unit 303 gives a signature created using the secret key of the server 300 to the CRL.
  • the controller and the device that use the CRL verify that the CRL is valid by verifying the signature attached to the CRL using the public key of the server 300.
  • the CRL issued by the CRL management unit is transmitted to the controller and the device via the communication unit 305.
  • the CRL holding unit 304 holds the CRL issued by the CRL management unit 303. Since the data structure of the CRL is the same as that held by the authentication information holding unit 104 of the controller 100, description thereof is omitted.
  • the communication unit 305 is a communication interface for communicating with the controller 100. Communication between the server 300 and the controller 100 is performed by, for example, SSL communication. The communication unit 305 holds a certificate necessary for SSL communication.
  • FIG. 10 and 11 are flowcharts showing an example of the procedure of device registration processing in each of the device and the controller.
  • FIG. 12 is an example of the procedure of device registration processing including the exchange between the device and the controller. It is the sequence diagram shown.
  • the device registration process is a process performed when the controller 100 and the device are connected, and is a procedure in which the device requests connection to the controller 100 and performs mutual authentication and then registers each other.
  • the outline of the processing in each of the device and the controller will be described according to the flowcharts of FIGS. 10 and 11, and then the device registration process including the exchange between the device and the controller will be described along the sequence diagram of FIG. A more detailed procedure will be described.
  • the device transmits the device ID and public key certificate of the device itself to the controller together with the connection request (step S1010).
  • the device performs a mutual authentication with the controller by executing a subroutine of “mutual authentication based on PKI to creation of shared key”, and then shares the shared key (step S1020). Details of the subroutine processing will be described later.
  • step S1020 If the return value of the subroutine in step S1020 is “normal” (YES in step S1030), the device executes the subroutine “mutual authentication using shared key to create information related to session” to share with the controller. After mutual authentication using a key, creation of a group key and a session key, which are information related to a session, and setting of a session validity period are performed (step S1040). Details of the subroutine processing will be described later.
  • step S1040 If the return value of the subroutine in step S1040 is “normal” (YES in step S1050), the device registers the controller information as a valid connection partner (step S1060).
  • step S1020 if the return value of the subroutine in step S1020 is “error” (NO in step S1030), or if the return value of the subroutine in step S1040 is “error” (NO in step S1050), the device is The registration process ends.
  • the controller waits for a device connection request, device ID, and public key certificate (step S1110). If these are not received (NO in step S1110), the controller continues to wait for a connection request from the device.
  • step S1110 the controller executes a sub-authentication with a device by executing a subroutine “mutual authentication based on PKI to create shared key”, and then shares the shared key. (Step S1120). Details of the subroutine processing will be described later.
  • step S1120 When the return value of the subroutine in step S1120 is “normal” (YES in step S1130), the controller executes the subroutine “Mutual authentication using shared key to create information related to session”, thereby After mutual authentication using the shared key, creation of a group key and session key, which are information related to the session, and setting of a session validity period are performed (step S1140). Further, the controller determines whether or not to set the device as a reference device (step S1140). Details of the subroutine processing will be described later.
  • step S1140 If the return value of the subroutine in step S1140 is “normal” (YES in step S1150), the controller transmits the controller and device information to the server 300 (step S1160).
  • the controller registers device information as a valid connection partner (step S1170).
  • step S1120 if the return value of the subroutine in step S1120 is “error” (NO in step S1130), or if the return value of the subroutine in step S1140 is “error” (NO in step S1150), the controller registers the device. The process ends.
  • the device registration process is a process performed when a new device is connected to the controller 100. For example, it is executed at the timing when a new device is added to the home area network to which the controller belongs, or when the power of a device existing in the network is turned off.
  • the device management unit 201 of the device 200a transmits a connection request to the controller 100 via the communication unit 206 (step S101). At this time, the device ID of the device 200a and the public key certificate are also transmitted.
  • the device management unit 101 of the controller 100 accepts a connection request via the communication unit 105 and causes the authentication processing unit 103 to execute mutual authentication based on PKI.
  • the authentication processing unit 103 of the controller 100 and the authentication processing unit 204 of the device 200a perform mutual authentication processing based on PKI and confirm each other's validity (step S102).
  • step S102 the authentication processing unit 103 of the controller 100 and the authentication processing unit 204 of the device 200a create a shared key by a key exchange method.
  • the shared key is used in mutual authentication performed thereafter.
  • step S102 “mutual authentication based on PKI to creation of shared key” is a subroutine for convenience, and the procedure will be described later.
  • the return value from the subroutine processing is “error”, the controller and the device end the device registration processing.
  • step S103 the authentication processing unit 103 of the controller 100 and the authentication processing unit 204 of the device 200a perform mutual authentication using the created shared key and create information related to the session.
  • step S103 the mutual authentication using the shared key is performed again in order to verify the shared key itself.
  • Creation of the shared key in step S102 is performed by a key exchange method. Accordingly, since the controller 100 and the device 200a each create a shared key according to a predetermined procedure, the shared key is used in step S103 in order to confirm that the created shared key is the same. It is useful to perform mutual authentication.
  • step S103 When mutual authentication using the shared key is successful, a group key, a session key, and a session valid period, which are information related to the session, are created (step S103). Also, it is determined whether or not the device 200a is set as a reference device (step S103). In step S103, “mutual authentication using a shared key to information creation related to a session” is a subroutine for convenience, and the procedure will be described later. When the return value from the subroutine processing is “error”, the controller and the device end the device registration processing.
  • the authentication processing unit 204 of the device 200a has, via the device management unit 201, the controller ID of the controller 100 and information on the shared key, group key, and session key shared with the controller 100 in the device information holding unit 203. Register in the connection controller management table 1100. Also, the session valid period is registered in the session remaining time item of the connection controller management table 1100 (step S104).
  • the device management unit 101 of the controller 100 transmits the controller ID related to the controller 100 and the certificate ID of the public key certificate, and the device ID related to the device 200a and the certificate ID of the public key certificate to the server 300 (Step S100). S105). At this time, the server performs SSL (Secure Socket Layer) communication.
  • SSL Secure Socket Layer
  • the device management unit 101 of the controller 100 registers the device ID of the device 200a and information on the shared key, group key, and session key shared with the device 200a in the connected device management table 1000 of the device information holding unit 102. .
  • the session valid period is registered in the session remaining time item of the connected device management table 1000.
  • the device 200a is set as a reference device, it is registered as a reference device in the item of reference device in the connected device management table 1000 (step S106).
  • step S103 “Mutual authentication using shared key to information creation related to session”, it is determined whether or not to set as a reference device. For example, the device that is first connected to the controller is the reference device. Is set.
  • the server 300 receives controller and device information from the controller 100 via the communication unit 305. Then, the device information management unit 301 registers the controller ID and certificate ID of the controller and the device ID and certificate ID of the authenticated device in the device information management table 1300 included in the device information holding unit 302 ( Step S107).
  • FIGS. 13 and 14 are flowcharts showing an example of the procedure of the session update process in each of the device and the controller.
  • FIG. 15 is an example of the procedure of the session update process including the exchange between the device and the controller. It is the sequence diagram shown.
  • the device and the controller 100 perform mutual authentication again, and then update the group key, session key, and remaining session time.
  • the outline of the processing in each of the device and the controller will be described along the flowcharts of FIGS. 13 and 14, and then the details of the processing including the exchange between the device and the controller will be described along the sequence diagram of FIG.
  • the device monitors the remaining session time to determine the start of session update. Alternatively, it waits for a session update notification from the controller (step S1210). If the remaining session time is greater than a predetermined value and no session update notification is received from the controller (NO in step S1210), monitoring is continued.
  • step S1210 If the remaining session time is less than a predetermined value or if a session update notification is received from the controller (YES in step S1210), the device sends a session update request to the controller in order to perform session update. Transmit (step S1220).
  • step S1230 After executing mutual authentication using the shared key with the controller by executing the subroutine “Mutual authentication using shared key to creating information related to session”, the group key and A session key is created and a session validity period is set (step S1230). Details of the subroutine processing will be described later.
  • step S1230 If the return value of the subroutine in step S1230 is “normal” (YES in step S1240), the device registers information related to the new session created in step S1230 as session update information (step S1250).
  • step S1230 if the return value of the subroutine in step S1230 is “error” (NO in step S1240), the device ends the session update process without updating the session.
  • the controller waits for a session update request from the device (step S1310). If not received (NO in step S1310), it continues to wait for a session update request from the device.
  • step S1310 When a session update request is received from the device (YES in step S1310), the mutual authentication using the device and the shared key is performed by executing the subroutine “Mutual authentication using shared key to creating information related to session”. After that, the group key and session key, which are information related to the session, are created, and the session valid period is set (step S1320). Details of the subroutine processing will be described later.
  • step S1320 If the return value of the subroutine in step S1320 is “normal” (YES in step S1330), the controller registers information relating to the new session created in step S1320 as session update information (step S1340). At this time, if the device is a reference device, information indicating that the other devices connected to the controller have not been updated is registered. If the device is not a reference device, information indicating that the device has been updated is registered. That is, after the reference device updates the session, whether each other device has updated the session or not has been managed for each device.
  • step S1320 if the return value of the subroutine in step S1320 is “error” (NO in step S1330), the session is not updated by not registering the session update information for the device.
  • a session update notification is transmitted to the device that has not updated the session.
  • session update notifications may be sent to all devices whose sessions have not been updated all at once, or some of them or one device may be sent.
  • a session update notification is sent to the unupdated device, and the session with all devices is updated by updating the session.
  • an apparatus in which an error has occurred is excluded.
  • the device 200a is a reference device and the device 200b is a device other than the reference device.
  • the sequence diagram shows an example in which no error occurs, but the processing when an error occurs is supplemented by text.
  • the device management unit 201 of the device 200a monitors the remaining session time 1160 held in the connection controller management table 1100, and confirms whether it is equal to or less than a predetermined threshold value. If the remaining session time is greater than the predetermined value, the remaining session time is continuously monitored (step S141).
  • the device management unit 201 of the device 200b also monitors the remaining session time as in the device 200a, but has a longer session remaining time than the device 200a. If a device other than the reference device has a session remaining time shorter than that of the reference device, there is no problem even if the session update process is performed first. At this time, for the group key, the group key used by the reference device is acquired in the subroutine of “Mutual authentication using shared key to session information creation” described later.
  • the same group key as the currently used group key is acquired, and the group key is not updated.
  • the session update state of the device other than the reference device is cleared, so that the device is determined to be a session-unupdated device, and a session update notification is received from the controller. To do.
  • the device updates the session, so that the device also updates the group key at the timing when the reference device updates the group key.
  • the device management unit 201 of the device 200a causes the authentication processing unit 204 to perform session update.
  • the authentication processing unit 204 transmits a session update request to the controller 100 via the communication unit 206 (step S142).
  • the device management unit 101 of the controller 100 receives a session update request via the communication unit 105 and causes the authentication processing unit 103 to execute mutual authentication processing.
  • the authentication processing unit 103 of the controller 100 and the authentication processing unit 204 of the device 200a confirm each other's validity by mutual authentication by challenge response authentication using a shared key (step S143). If mutual validity is confirmed by mutual authentication, a group key, a session key, and a session valid period, which are information related to the session, are created (step S143).
  • step S143 “Mutual authentication using shared key to information creation related to session” is the same process as step S103 in the device registration process, and is a subroutine for convenience, and the procedure will be described later.
  • the controller and the device 200a do not update the session. That is, the process proceeds to step S146 without performing the session update information registration process in steps S144 and S145.
  • the device 200b is set as the reference device in the subsequent “mutual authentication using shared key to information creation related to session” subroutine.
  • the device management unit 201 of the device 200a registers the session key, group key, and session valid period created in step S143 in the connection controller management table 1100 of the device information holding unit 203 (step S144). At this time, the session valid period is registered in the session remaining time item.
  • the device management unit 101 of the controller 100 registers the group key, session key, and session valid period created in step S143 in the connected device management table 1000 of the device information holding unit 102.
  • the session valid period is registered in the item of session remaining time 1060.
  • the session update state 1070 related to the device 200a is set to “updated”.
  • the item of the session update state 1070 is updated to “unupdated” (step S145).
  • the device management unit 101 of the controller 100 refers to the item of the session update state 1070 of the connected device management table 1000 held by the device information holding unit 102 and confirms the presence / absence of an “unupdated” device. If there is no device for which the item of the session update state 1070 is “unupdated”, it is determined that session update processing has been performed for all devices, and the processing ends.
  • the device management unit 101 of the controller 100 sends a session update notification to the device (step S146).
  • a session update notification is given to the device 200b whose session has not been updated. If there are other devices that have not been updated, a session update notification is also sent to the device, and the subsequent processing is performed.
  • a session update notification may be sent to all devices whose sessions have not been updated. Alternatively, it may be sent to one of the unupdated devices, or may be sent every several devices.
  • the device management unit 201 of the device 200b receives the session update notification transmitted by the controller 100 via the communication unit 206, and causes the authentication processing unit 204 to perform session update. First, the authentication processing unit 204 transmits a session update request to the controller 100 via the communication unit 206 (step S147).
  • the device 200b which is a device other than the reference device, also performs session update in the same procedure as steps S143 to S145 related to the device 200a that is the reference device (steps S148 to S150).
  • step S149 the device management unit 101 of the controller 100 registers the group key, session key, and session validity period created in step S148 in the connected device management table 1000 of the device information holding unit 102.
  • the item of the session update state 1070 is updated to “updated” (step S149).
  • step S145 described above by transmitting a session update notification to all the devices that have not been updated, the controller updates the session with all the devices and shares the updated group key.
  • FIGS. 16 and 17 are flowcharts showing an example of the procedure of mutual authentication to shared key creation based on PKI in each of the device and the controller.
  • FIG. 18 shows the exchange between the device and the controller. It is the sequence diagram which showed an example of the procedure of the process including. The outline of the processing in each of the device and the controller will be described along the flowcharts of FIGS. 16 and 17, and the details of the processing including the exchange between the device and the controller will be described along the sequence diagram of FIG. 18.
  • the device waits for the controller ID and public key certificate from the controller. If these are not received (NO in step S1410) and an error is received (YES in step S1420), “error” is set as a return value of the subroutine (step S1460).
  • step S1410 and NO in step S1420 If neither the controller ID and the public key certificate nor the error is received from the controller (NO in step S1410 and NO in step S1420), the controller continues to wait for information from the controller.
  • step S1410 When the controller ID and the public key certificate are received (YES in step S1410), it is confirmed that the certificate ID is not in the CRL for the public key certificate received from the controller (step S1430).
  • step S1440 If the certificate ID is not described in the CRL and has not been revoked (NO in step S1430), the signature attached to the public key certificate is verified (step S1440).
  • step S1440 if the verification of the signature of the controller public key certificate is successful (YES in step S1440), the device notifies the controller of the verification success (step S1470).
  • the devices share a shared key by exchanging keys with the controller (step S1480).
  • the key is used for subsequent mutual authentication.
  • the device sets “normal” as a return value of the subroutine (step S1490).
  • step S1430 if the certificate ID of the public key certificate is described in CRL (YES in step S1430), or if the signature verification is not successful (NO in step S1440), the controller is disclosed. Upon determining that the verification of the key certificate has failed, the device transmits an error notification to the controller (step S1450). Then, “error” is set as the return value of the subroutine (step S1460).
  • step S1490 or step S1460 is returned to the caller process as the processing result of the subroutine (step S1500).
  • the controller confirms that the certificate ID of the public key certificate received from the device is not in the CRL (step S1610).
  • step S1620 If the certificate ID is not described in the CRL and has not expired (NO in step S1610), the signature attached to the public key certificate is verified (step S1620).
  • step S1610 If the certificate ID of the public key certificate is described in CRL (YES in step S1610) or if the signature verification is not successful (NO in step S1620), the public key of the device Assuming that the verification of the certificate has failed, the controller transmits an error notification to the device (step S1630).
  • step S1670 “error” is set as a return value of the subroutine.
  • step S1620 when the verification of the controller's public key certificate is successful (YES in step S1620), the device waits for the verification result of the controller's public key certificate (step S1650).
  • step S1670 If an error notification is received without receiving a verification success from the device (NO in step S1650) (YES in step S1660), “error” is set as the return value of the subroutine (step S1670).
  • step S1650 If the verification success is not received from the device (NO in step S1650) and no error is received (NO in step S1660), the verification result from the device is kept waiting.
  • step S1650 If a verification success is received from the device (YES in step S1650), the controller and the device share a shared key by key exchange (step S1680). The key is used for subsequent mutual authentication.
  • the controller sets “normal” as the return value of the subroutine (step S1690).
  • step S1690 or step S1670 is returned to the caller process as the processing result of the subroutine (step S1700).
  • the authentication processing unit 103 of the controller 100 confirms that the certificate ID of the public key certificate of the device 200a is not described in the CRL held by the authentication information holding unit 104 (step S111).
  • step S111 if the certificate ID of the device 200a is not described in the CRL, the authentication processing unit 103 of the controller 100 has an appropriate digital signature of the certificate authority given to the public key certificate of the device 200a. It is verified whether it exists (step S112).
  • the digital signature method and the verification method used at this time are based on ECDSA (Elliptic Curve Digital Signature Algorithm).
  • ECDSA Elliptic Curve Digital Signature Algorithm
  • the authentication processing unit 103 determines that the device 200a is not a valid device, An error notification is sent to the device 200a, and a return value "error" is returned to the device registration process that is the caller of the subroutine. At this time, the device 200a that has received the error notification also returns a return value “error”, and both the controller and the device end the subroutine processing.
  • step S112 when the verification of the electronic signature is successful, the authentication processing unit 103 of the controller 100 determines that the device 200a is a valid device, and the controller ID and public key certificate of the controller itself via the communication unit 105. The document is transmitted to the device 200a (step S113).
  • the device management unit 201 of the device 200a receives the controller ID and public key certificate of the controller 100 via the communication unit 206, and causes the authentication processing unit 204 to execute an authentication process based on PKI. First, the authentication processing unit 204 confirms that the certificate ID of the public key certificate of the controller is not described in the CRL held by the authentication information holding unit 205 (step S114).
  • step S114 when the certificate ID of the controller 100 is not described in the CRL, the authentication processing unit 204 of the device 200a has an appropriate digital signature of the certificate authority given to the public key certificate of the controller 100. It is verified whether it exists (step S115).
  • the electronic signature method and the verification method used at this time are based on ECDSA (Electric Curve Digital Signature Algorithm) as in step S112, and the description thereof is omitted.
  • the authentication processing unit 204 determines that the controller 100 is not a valid device, and the controller Is returned to the device registration processing that is the caller of the subroutine. At this time, the controller that receives the error notification also returns a return value “error”, and both the controller and the device end the subroutine processing.
  • step S115 if the verification of the electronic signature is successful, the authentication processing unit 204 of the device 200a determines that the controller 100 is a valid controller and notifies the controller 100 of the verification success (step S116).
  • the authentication processing unit 204 of the device 200a and the authentication processing unit 103 of the controller 100 perform key exchange as processing for sharing the shared key (steps S117 and S118).
  • the key exchange method to be implemented is ECDH (Eliptic Curve Diffie-Hellman) which is a key exchange method using elliptic curve cryptography.
  • ECDH Eliptic Curve Diffie-Hellman
  • the authentication processing unit 103 of the controller 100 calculates a value by a predetermined procedure using the controller's own private key and the public key of the device 200a included in the public key certificate of the device 200a.
  • the authentication processing unit 204 of the device 200a calculates a value by a predetermined procedure using the private key of the device itself and the public key of the controller 100 included in the public key certificate of the controller 100.
  • the values calculated in the controller 100 and the device 200a are the same.
  • the shared key is calculated from the values shared in this way.
  • a 128-bit key length of AES Advanced Encryption Standard
  • AES Advanced Encryption Standard
  • FIG. 19 and 20 are flowcharts showing an example of a procedure for creating information related to mutual authentication to session using a shared key in each of the device and the controller.
  • FIG. It is the sequence diagram which showed an example of the procedure of the same process including exchange.
  • challenge response authentication using random numbers is performed as mutual authentication using a shared key.
  • the device waits for reception of the random number A created by the controller from the controller, and continues to wait if it does not receive (NO in step S1810).
  • the device When the random number A is received from the controller (YES in step S1810), the device encrypts the received random number A and creates a random number B that is another random number (step S1820).
  • the device transmits the encrypted random number A ′ and the random number B, which are the encrypted random number A, to the controller (step S1830).
  • the device waits for processing on the controller side. If an error is received from the controller without receiving the encrypted random number B ′, the encrypted session key, the encrypted group key, and the session valid period (NO in step S1840), the subroutine returns. “Error” is set as a value (step S1880).
  • step S1840 If the controller does not receive the encrypted random number B ′, the encrypted session key, the encrypted group key, and the session validity period (NO in step S1840) and does not receive an error (NO in step S1850), any of the values from the controller Continue to wait for receipt of information.
  • the device When the device receives the encrypted random number B ', the encrypted session key, the encrypted group key, and the session validity period from the controller (YES in step S1840), the device first performs verification on the random number B (step S1860). The device decrypts the received encrypted random number B ′ with the shared key held. If the value of the decryption result matches the random number B created by the device itself in step S1820, it is determined that the random number B has been successfully verified.
  • step S1860 If the verification of the random number B is not successful (NO in step S1860), an error notification is sent to the controller (step S1870).
  • step S1860 If the verification of the random number B is successful (YES in step S1860), the group key and session key received from the controller are decrypted (step S1890).
  • the device notifies the controller of the verification success (step S1900).
  • step S1910 or step S1880 is returned to the calling source process as the processing result of the subroutine (step S1920).
  • the controller creates a random number A and transmits it to the device (step S2010).
  • step S2020 it waits for an encrypted random number A ′ and a random number B created by processing on the device side.
  • the process continues to wait until it is received.
  • step S2020 When the encrypted random number A ′ and the random number B are received (YES in step S2020), verification regarding the random number A is performed (step S2030).
  • the device decrypts the received encrypted random number A ′ with the held shared key. If the value of the decryption result matches the random number A created by the controller itself in step S2010, it is determined that the random number A has been successfully verified.
  • step S2030 If the verification of the random number A is not successful (NO in step S2030), an error notification is sent to the device (step S2040). Then, “error” is set as a return value of the subroutine (step S2150).
  • step S2030 If the verification of the random number A is successful (YES in step S2030), the random number B received from the device is encrypted (step S2050).
  • the device is a reference device (step S2060). If the device is the first device that has made a connection request to the controller, or if the device has been disconnected from the reference device, such as when the reference device has not been set, the device Equipment.
  • step S2060 If the device is a reference device (YES in step S2060), a group key is created (step S2070). On the other hand, if the device is not a reference device (NO in step S2060), group key data is acquired in order to share the group key already created and held with the device (step S2080).
  • controller creates a session key and sets a session valid period (step S2090).
  • the group key and session key are encrypted with the shared key (step S2100).
  • the encrypted random number B ′, the encrypted session key, the encrypted group key, and the session validity period acquired in the processes of steps S2050 to S2100 are transmitted to the device (step S2110).
  • step S2120 When waiting for the verification result on the device side and not receiving verification success (NO in step S2120) and receiving an error (YES in step S2140), “error” is set as a return value of the subroutine (step S2120). S2150).
  • step S2120 If the verification result on the device side is not received (NO in step S2120) and no error is received (NO in step S2140), the result from the device is kept waiting.
  • step S2130 If a verification success is received from the device (YES in step S2120), “normal” is set as the return value of the subroutine (step S2130).
  • step S2130 or step S2150 is returned to the process of calling the subroutine (step S2160).
  • the authentication processing unit 103 of the controller 100 creates an arbitrary random number A and transmits it to the device 200a (step S121).
  • the authentication processing unit 204 of the device 200a encrypts the random number A received via the communication unit 206 using the held shared key, and creates an encrypted random number A '(step S122). Further, the authentication processing unit 204 creates an arbitrary random number B (step S122).
  • the authentication processing unit 204 of the device 200a transmits the encrypted random number A ′ and the random number B encrypted in step S122 to the controller 100 (step S123).
  • the authentication processing unit 103 of the controller 100 receives the encrypted random number A ′ and the random number B.
  • the authentication processing unit 103 decrypts the encrypted random number A ′ with the shared key.
  • the authentication processing unit 103 determines that the verification for the random number A has been successful (step S124).
  • step S124 when the verification of the random number A is not successful, the authentication processing unit 103 of the controller notifies the device of an error and returns a return value “error” to the caller of the subroutine. At this time, the device that has received the error notification also returns a return value “error”, and both the controller and the device end the subroutine processing.
  • step S124 when the verification of the random number A is successful, the authentication processing unit 103 of the controller encrypts the random number B received from the device 200a with the shared key and creates an encrypted random number B '(step S125).
  • the authentication processing unit 103 of the controller refers to the item of the reference device 1080 in the connected device management table 1000 of the device information holding unit 102 and confirms whether the device 200a is a reference device. If the device 200a is a reference device, a group key is created (step S126). Since the group key has an AES key length of 128 bits and is created using any general technique, description thereof is omitted. In addition, when the reference device is not set, such as when the device 200a is the device that first made a connection request to the controller or when the connection with the reference device is disconnected, The device 200a is set as a reference device, and a group key is created.
  • the authentication processing unit 103 has already been created from the connected device management table 1000 held by the device information holding unit 102. Get group key information.
  • the authentication processing unit 103 of the controller creates a session key (step S127).
  • the session key is created using an arbitrary general technique with an AES key length of 128 bits.
  • the authentication processing unit 103 of the controller sets a session valid period (step S128).
  • the authentication processing unit 103 sets a predetermined value (for example, 24 hours or 72 hours) as the session valid period.
  • the controller authentication processing unit 103 encrypts the group key and session key information obtained in steps S126 and S127 using the shared key (step S129).
  • the authentication processing unit 103 sends the encrypted random number B ′ encrypted in step S125, the encrypted group key encrypted in step S129, the encrypted session key, and the session valid period set in step S128 via the communication unit 105. Is transmitted to the device 200a (step S130).
  • the authentication processing unit 204 of the device 200a verifies the encrypted random number B 'received from the controller 100 (step S131).
  • the authentication processing unit 204 decrypts the encrypted random number B ′ with the held shared key.
  • the authentication processing unit 204 determines that the random number B has been successfully verified.
  • the authentication processing unit 204 determines that the controller 100 is not a valid controller, notifies the controller 100 of an error, and returns a return value to the caller of the subroutine. Returns “error”. At this time, the controller that receives the error notification also returns a return value “error”, and both the controller and the device end the subroutine processing.
  • step S131 if the random number B is successfully verified, the authentication processing unit 204 of the device 200a decrypts the encrypted group key and the encrypted session key with the shared key (step S132).
  • the authentication processing unit 204 of the device 200a notifies the controller 100 of the verification success (Step S133).
  • FIG. 22 is a sequence diagram illustrating an example of a procedure for transmitting device history information from the device 200 a to the server 300. Transmission of such device history information is performed regularly or irregularly. In the following, the procedure will be described as an example of the device 200a, but the processing procedure is the same for the devices 200b and 200c.
  • the device management unit 201 of the device encrypts the device history information stored in the device history holding unit 202 with the session key, and transmits it to the controller 100 together with the device ID of the device itself (step S161).
  • the device management unit 101 of the controller 100 receives the device ID and the encrypted device history information via the communication unit 105. Then, the session key associated with the device ID is acquired from the connected device management table 1000 of the device information holding unit 102, and the received device history information is decrypted (step S162).
  • the communication unit 105 of the controller 100 and the communication unit 305 of the server 300 perform SSL authentication and establish an encrypted communication path (step S163).
  • SSL authentication uses a general technique, description thereof is omitted.
  • the device management unit 101 of the controller 100 transmits the controller ID of the controller itself, the device ID received from the device, and the decrypted device history information to the server 300 via the communication unit 105 (step S164).
  • the device information management unit 301 of the server 300 registers the controller ID, device ID, and device history information received via the communication unit 305 in the device information management table 1300 included in the device information holding unit 302 (step S165).
  • FIG. 23 is a sequence diagram illustrating an example of a procedure in which the server 300 executes control of the device 200a.
  • the server 300 transmits control request information for controlling the device 200 a to the controller 100.
  • the controller 100 that has received the control request creates and transmits a control command for the device 200a, and causes the device 200a to execute a function corresponding to the control request.
  • Such a control request from the server 300 to the device 200a is made periodically or irregularly.
  • the control request includes, for example, a function to be executed by the device and contents to be displayed on the display.
  • the communication unit 305 of the server 300 and the communication unit 105 of the controller 100 perform SSL authentication and establish an encrypted communication path (step S171).
  • the device information management unit 301 of the server 300 creates control request information for causing the device 200a to execute a predetermined operation. And it transmits to the controller 100 via the communication part 305 (step S172).
  • the device management unit 101 of the controller 100 receives control request information via the communication unit 105. Then, the device management unit 101 confirms what control request the control request information is for which device in the network, and creates a control command to be executed by the device 200a in response to the control request. (Step S173).
  • step S173 If the control command created in step S173 is an instruction for a plurality of devices, the device management unit 101 of the controller 100 encrypts the control command using the group key (step S174). At this time, information indicating that encryption is performed using the group key may be added to the header portion of the control command to be transmitted.
  • step S173 When the control command created in step S173 is an instruction for a single device, the device management unit 101 of the controller 100 encrypts the control command using the session key (step S175). At this time, information indicating that the session key is encrypted may be added to the header portion of the control command to be transmitted.
  • the communication unit 105 of the controller 100 transmits the control command encrypted using the group key or the session key to the target device (step S176).
  • the device 200a receives the encrypted control command via the communication unit 105, and decrypts it with the group key or the session key (step S177). At this time, the determination as to whether to use the group key or the session key may be made using the information added to the header portion in step S174 or step S175. Alternatively, the control command may be decrypted using each of the group key and the session key, and the determination may be made using the decryption result.
  • the transmission source device uses a MAC including a header, a transmission source address, and a transmission destination address in addition to encryption of the device history information.
  • the generated MAC is transmitted together with the encrypted device history information.
  • the MAC including the header, transmission source address, transmission destination address, and device history information
  • the alteration can be detected by performing the MAC verification.
  • the device 200a is connected to all other devices (here, the device 200b) and the controller 100 connected to the home area network 400 with reference to FIGS.
  • the device history information is multicast transmitted.
  • FIG. 24 is a data configuration diagram of the message format before encryption and after encryption.
  • FIG. 24A shows device history information before encryption (hereinafter referred to as device history information before encryption and control information before encryption in control information MAC transmission processing to be described later). Is also a data structure diagram of a message format before encryption.
  • the message format before encryption is composed of a header 2401, a transmission source address 2402, a transmission destination address 2403, and transmission data 2404.
  • the header 2401 includes a fragment flag, a fragment number, and the like given when transmission data is divided into a plurality of packets.
  • the transmission source address 2402 is an address of a device that transmits the transmission data 2404, for example, an IP (Internet Protocol) address, a MAC (Media Access Control) address, and the like, and includes information for identifying the device to be transmitted.
  • IP Internet Protocol
  • MAC Media Access Control
  • the transmission destination address 2403 is an address of a device or a controller that receives the transmission data 2404, for example, an IP address, a MAC address, and the like, and includes information for identifying the receiving device or the controller.
  • a multicast address in multicast transmission may be included.
  • the device 200 encrypts the transmission data 2404 as plain text.
  • a MAC is generated using the header 2401, the transmission source address 2402, the transmission destination address 2403, and the transmission data 2404 as plain text.
  • the encryption may be performed using AES, and the MAC may be generated using AES CBC-MAC (Cipher Block Chaining MAC) or HMAC (Hash-based MAC).
  • encryption and creation of authentication data may be performed by encryption with authentication such as AES-CCM (Counter with CBC MAC) or AES-GCM (Galois / Counter Mode). Even when encryption with authentication is performed, the encryption is performed using the transmission data 2404 as plain text, and the MAC generation is performed using the header 2401, the transmission source address 2402, the transmission destination address 2403, and the transmission data 2404 as plain text.
  • FIG. 24 (b) is a data structure diagram of the message format after encryption.
  • the encrypted message format includes a header 2401, a transmission source address 2402, a transmission destination address 2403, and encrypted data 2405 with authentication.
  • Authenticated encrypted data 2405 is data obtained by combining encrypted transmission data and MAC.
  • FIG. 25 shows, as an example of the device history information MAC transmission processing procedure, from the device 200a to all other devices and controllers (here, the device 200b and the controller 100) connected to the home area network 400.
  • FIG. 6 is a sequence diagram showing a procedure for multicast transmission of device history information.
  • Such transmission of device history information is performed regularly or irregularly.
  • the device 200a encrypts the device history information stored in the device history holding unit 202 with the group key. At this time, information indicating that encryption is performed using the group key may be added to the header portion of the history information to be transmitted.
  • the device 200a generates a MAC from the header, the transmission source address, the transmission destination address, and the history information (step S2501).
  • the device 200a uses broadcast communication to authenticate the device 200b and the controller 100 in the encrypted message format shown in FIG.
  • the encrypted data is transmitted (step S2502).
  • the device 200a also transmits its own device ID.
  • the controller 100 decrypts the encrypted transmission data received from the device 200a with the group key to obtain device history information, and performs MAC verification using the header, the transmission source address, the transmission destination address, and the transmission data. This is performed (step S2503). At this time, when information indicating that encryption is performed with the group key is added to the header, it may be determined with reference to the information to decrypt with the group key.
  • step S2504 when the MAC verification is successful (step S2504: Yes), the controller 100 performs SSL authentication with the server 300 and establishes an encryption communication path (step S2505).
  • the controller 100 transmits its controller ID, the device ID received from the device 200a, and the decrypted device history information to the server 300 (step S2506).
  • the server 300 registers the controller ID, device ID, and device history information received from the controller 100 in the device information management table 1300 included in the device information holding unit 302 (step S2507).
  • step S2504 when the MAC verification is not successful (step S2504: No), the controller 100 does not transmit the device history information to the server 300. Further, when the MAC verification is not successful, a notification that the MAC verification is not successful may be made to all other devices and controllers connected to the home area network 400.
  • the device 200b obtains device history information by decrypting the encrypted transmission data received from the device 200a with the group key, and performs MAC verification using the header, the transmission source address, the transmission destination address, and the transmission data. This is performed (step S2508). At this time, when information indicating that encryption is performed with the group key is added to the header, it may be determined with reference to the information to decrypt with the group key.
  • step S2509 when the MAC verification is successful (step S2509: Yes), the device 200b can perform a process using the device history information (step S2510).
  • step S2509 If the MAC verification is not successful in the processing of step S2509 (step S2509: Yes), the device 200b does not perform processing using the device history information. Further, when the MAC verification is not successful, a notification that the MAC verification is not successful may be made to all the other devices 200 and the controller 100 connected to the home area network 400.
  • the device history information MAC transmission processing has been described by taking as an example a case where the device 200a multicast-transmits the device history information to all other devices 200 and the controller 100 connected to the home area network 400. .
  • step S2502 an example in which the device 200a transmits the device history information only to the controller 100 and not to other devices connected to the home area network 400 is also conceivable.
  • step S2501 the device 200a encrypts the device history information with the session key.
  • step S2503 the controller 100 decrypts the device history information. It may be decrypted with a key.
  • Control information MAC transmission process When a control command is transmitted from a controller to a device, spoofing transmission to a transmission source controller by a third party who is not originally permitted to transmit the control command may be a problem.
  • the transmission source controller in order to counter the spoofed transmission described above, includes a header, a transmission source address, a transmission destination address, and a control command in addition to the encryption of the control command. And the generated MAC is transmitted together with the encrypted control command.
  • MAC verification is performed on the MAC including the header, transmission source address, transmission destination address. The alteration can be detected.
  • FIG. 24A is a data structure diagram of a message format before encryption as described above.
  • the transmission data 2404 is device history information before encryption.
  • the transmission data 2404 is a control command before encryption. It is an example of the case.
  • FIG. 24B is a data configuration diagram of the message format after encryption as described above.
  • the encrypted data 2405 with authentication is data obtained by combining the encrypted history information and the MAC has been described.
  • the encrypted data 2405 with authentication is used. Is an example in which the data is a combination of the encrypted control command and the MAC.
  • FIG. 26 is a sequence diagram illustrating an example of a control information MAC transmission processing procedure.
  • This control information MAC transmission process is partly changed from the control information transmission process described above.
  • Such control information MAC transmission processing is performed regularly or irregularly.
  • step S2601 to step S2603 is the same as the processing from step S171 to step S173 in the control information transmission processing. For this reason, since description of these processes has already been described, a description thereof will be omitted.
  • step S2603 When the process of step S2603 is completed, if the control command generated in the process of step S2603 is an instruction for a plurality of devices, the controller 100 encrypts the generated control command with the group key. At this time, information indicating that encryption is performed with the group key may be added to the header portion of the control command to be transmitted.
  • the controller 100 generates a MAC from the header, the transmission source address, the transmission destination address, and the control command (step S2604).
  • control command generated in the process of step S2603 is an instruction for a single device
  • the controller 100 encrypts the generated control command with the session key.
  • information indicating that encryption is performed with the group key may be added to the header portion of the control command to be transmitted.
  • the controller 100 generates a MAC from the header, the transmission source address, the transmission destination address, and the control command (step S2605).
  • the controller transmits the encrypted data with authentication in the message format after encryption shown in FIG. 24B to the target device (step S2606).
  • the device that has received the encrypted data with authentication (here, the device 200a will be described as a representative of the device that has received the encrypted data with authentication), for example, transmits the encrypted transmission data received from the controller 100.
  • the control command is obtained by decrypting with the group key or session key, and MAC verification is performed using the header, the transmission source address, the transmission destination address, and the transmission data (step S2607).
  • the group key or the session key is referred to by referring to the information. It may be determined whether to use the decoding.
  • step S2608 when the MAC process is successful (step S2608: Yes), the device 200a operates according to the instruction of the decoded control command (step S2609).
  • step S2608 when the MAC process is not successful (step S2608: No), the device 200a does not follow the instruction of the decoded control command. Further, when the MAC verification is not successful, a notification that the MAC verification is not successful may be made to all the other devices 200 and the controller 100 connected to the home area network 400.
  • the MAC target (see FIG. 24A) is composed of a header 2401, a transmission source address 2402, a transmission destination address 2403, and transmission data 2404.
  • the MAC target may consist only of the transmission data 2404.
  • the transmission data 2404 includes a counter, a sequence number, and the like. Since the session key is shared only by the controller 100 and the corresponding device 200, impersonation and retransmission attacks by a third party are difficult.
  • control command may be transmitted as follows.
  • the plurality of control commands may be transmitted as a plurality of transmission data.
  • a fragment flag, a fragment number, and the like are added to the headers of a plurality of transmission data for transmission.
  • the device 200 that has received the transmission data executes the control command after receiving a plurality of transmission data because the control command is composed of a plurality of transmission data.
  • encryption and MAC are generated for all transmission data, if any MAC verification of a plurality of transmission data is not successful, the control command is not executed. Further, when any MAC verification among the plurality of transmission data is not successful, the transmission data may be discarded without performing MAC verification of the transmission data to which the subsequent fragment flag is assigned. Thereby, the processing of the received device 200 and the controller 100 can be reduced.
  • MAC When MAC is not generated for all transmission data, the header, transmission source address, transmission destination address, and control command of all transmission data are combined, MAC is generated, and MAC is assigned to the last transmission data. Also good. Thereby, it is possible to verify the integrity of all the transmission data by executing the MAC verification only once, and the processing of the received device 200 and the controller 100 can be lightened.
  • control information MAC transmission process has been described on the assumption that the transmission data 2404 is a control command.
  • the present invention is not limited to the case where the transmission data 2404 is a control command.
  • the transmission data 2404 is transmitted from the server 300 to the device 200a.
  • An example of notification is also conceivable.
  • step S2603 does not occur, and the controller 100 uses the notification received from the server 300 as it is as the transmission data 2404 and performs the processes after step S2604.
  • step S2608 when the MAC process is successful (step S2608: Yes), the device 200a performs a process of storing the decoded notification instead of performing the process of step S2609. If the MAC process is not successful (step S2608: No), the process of storing the decrypted notification is not performed.
  • a reference device is provided from a plurality of devices connected to the controller, and the controller sends an update notification to the other device at the timing of updating the group key in the reference device. Update is executed. This makes it possible to synchronize the group key update timings of multiple devices connected to the controller, and even if the controller and each device perform mutual authentication and group key update, the controller can simultaneously transmit encrypted information. Can do.
  • Second Embodiment> ⁇ 2-1. Overview>
  • the authentication system according to the present embodiment is different in that the controller sets the remaining session time with each device so as to have a similar value at the same time.
  • the configuration of the authentication system, controller, device, and server in the present embodiment is the same as that of the authentication system 10, controller 100, devices 200a to 200c, and server 300 in the first embodiment.
  • the data structure of the connected device management table held by the device information holding unit 102 of the controller 100 is partially different from that of the first embodiment.
  • FIG. 24 is a diagram showing an example of the data structure and data of the connected device management table 2000 in the present embodiment.
  • the connected device management table 2000 holds a connected device management record group that is data for each connected device, and each record includes a device ID 2010, a certificate ID 2020, a shared key 2030, a group key 2040, and a session key. 2050, session remaining time 2060, session update status 2070, and reference device 2080 are included.
  • the difference from the first embodiment is that the remaining session time 2060 is set to a common value for devices having the same group key 2040. For example, in FIG. 24, device ID 1 and device ID 2 hold the same group key “11223...” And the session remaining time has the same value of “13:40:50”. is doing.
  • the authentication system 10 also uses “device registration processing”, “session update processing”, “PKI-based mutual authentication to shared key creation”, “shared key use”. Mutual authentication to creation of information relating to session ”,“ device history information transmission processing ”, and“ control information transmission processing ”.
  • device registration processing e.g., a procedure of “mutual authentication using a shared key to creation of information related to a session” will be described, and other processes will be described in order focusing on differences from the first embodiment.
  • the controller and the device perform mutual authentication using the shared key, and the group key and session, which are information related to the session Create key and session validity period.
  • step S128 the method for setting the session valid period of the controller 100 in step S128 is different from that in the first embodiment.
  • the authentication processing unit 103 of the controller 100 sets a predetermined value (for example, 24 hours or 72 hours) as the session valid period when the device is a reference device. However, if the device is not a reference device, the session valid period is set as follows (step S128).
  • the authentication processing unit 103 of the controller 100 refers to the remaining session time 2060 of the connected device management table 2000 included in the device information holding unit 102 and acquires the remaining session time value of the reference device. Then, the acquired value is set as the session valid period of the device.
  • the data of the connected device management table 2000 shown in FIG. 24 will be described as an example.
  • the remaining session of the device ID 1 that is the reference device from the connected device management table 2000 is set.
  • the time is acquired and set as the session valid period of the device ID 2.
  • the reference device and the device other than the reference device It will have an approximate session remaining time.
  • the controller and the device follow the connection request, mutual authentication based on PKI, creation of the shared key, mutual use using the shared key, in steps S101 to S107 in the sequence diagram of FIG. Create information related to authentication and session, and register each controller and device.
  • step S103 the session remaining period of the reference device is set as the session valid period of the device that is not the reference device.
  • step S104 the session valid period registered by the device side is similar to the first embodiment in that the session valid period received from the controller 100 is registered as the remaining session time regardless of whether the device is a reference device. .
  • the session remaining period item may be registered in a form that shares the remaining session time of the reference device, or the session set in step S103.
  • the valid period may be registered as the remaining session time.
  • step S103, step S104, and step S106 in the sequence diagram of FIG. 12 are carried out without delay, and the reference device set in the connected device management table 2000 of the controller 100.
  • the remaining session time for a device that is not a reference device and the remaining session time set in the connection controller management table 1100 on the device side have approximate values.
  • FIG. 25 and FIG. 26 are flowcharts showing an example of the procedure of session update processing in the present embodiment in each of the device and the controller.
  • FIG. 27 shows the session update including the exchange between the device and the controller. It is a sequence diagram which shows an example of the procedure of a process.
  • the device monitors the remaining session time set with the controller and confirms whether or not it is equal to or less than a predetermined value (step S3010). If the remaining session time is greater than the predetermined value (NO in step S3010), monitoring is continued.
  • the device transmits a session update request to the controller in order to update the session (step S3020).
  • step S3030 After executing mutual authentication using the shared key with the controller by executing the subroutine “Mutual authentication using shared key to creating information related to session”, the group key and A session key is created and a session validity period is set (step S3030).
  • step S3030 If the return value of the subroutine in step S3030 is “normal” (YES in step S3040), the device registers information related to the new session created in step S3030 as session update information (step S3050).
  • step S3030 if the return value of the subroutine in step S3030 is “error” (NO in step S3040), the session update process is terminated without updating the session.
  • the controller waits for a session update request from the device (step S3110). If not received (NO in step S3110), it continues to wait for a session update request from the device.
  • the controller When the controller receives a session update request from the device (YES in step S3110), the controller performs mutual authentication using the device and the shared key by executing a sub-routine “Mutual authentication using shared key to creating information related to session”. After setting, the group key, session key, and session validity period, which are information related to the session, are set (step S3120).
  • step S3130 If the return value of the subroutine in step S3130 is “normal” (YES in step S3130), the controller registers information related to the new session created in step S3120 as session update information (step S3140).
  • step S3120 if the return value of the subroutine in step S3120 is “error” (NO in step S3130), the session update with the device that is executing the session update is not performed.
  • step S3150 If there is another device that has not updated the session (YES in step S3150), the process returns to the first step and waits for a session update request from the unupdated device (step S3110).
  • FIG. 27 it is assumed that the device 200a is a reference device and the device 200b is a device other than the reference device.
  • the device management unit 201 of the device instructs the authentication processing unit 204 to update the session when the remaining session time becomes a predetermined threshold value or less.
  • the authentication processing unit 204 that has received the instruction transmits a session update request to the controller 100 via the communication unit 206 (steps S202 and S207).
  • step S202 and step S207 are performed at similar timings, the group key update between the controller and each device is performed at the same timing.
  • the reference device and the device other than the reference device are It has a value that approximates the remaining session time. Therefore, by performing session update processing based on the remaining session time for each device, it will be performed at a timing that approximates the update of the group key. Even if the controller and each device perform mutual authentication and group key update, The controller can perform simultaneous transmission of encrypted information.
  • the configuration of the authentication system, controller, device, and server in the present embodiment is the same as that of the authentication system 10, controller 100, devices 200a to 200c, and server 300 in the second embodiment.
  • part of the data structure of the connected device management table held by the device information holding unit 102 of the controller 100 and part of the data structure of the connected controller management table held by the device information holding unit 203 of the device are Different from form.
  • FIG. 28 is a diagram illustrating an example of the data structure and data of the connected device management table 3000 included in the device information holding unit 102 of the controller 100 in the present embodiment.
  • the connected device management table 3000 stores a connected device management record group that is data for each connected device, and each record includes a device ID 3010, a certificate ID 3020, a shared key 3030, and a group key (current) 3040. , Group key (new) 3050, session key 3060, remaining session time 3070, session update status 3080, and reference device 3090 are included.
  • the group key has two items: a group key (current) and a group key (new).
  • FIG. 29 is a diagram illustrating an example of the data structure and data of the connection controller management table 3100 included in the device information holding unit 203 of the device in the present embodiment.
  • the connection controller management table 3100 stores a connection controller management record group that is data of connected controllers, and each record includes a controller ID 3110, a certificate ID 3120, a shared key 3130, a group key (current) 3140, The items of group key (new) 3150, session key 3160, and remaining session time 3170 are included.
  • the group key has two items, a group key (current) and a group key (new).
  • encryption of information that the controller transmits to each device at once is performed using an encryption key held as a group key (current) by the controller and each device.
  • the group key (new) is an item that holds a newly created group key in the session update process between the controller and the reference device.
  • the authentication system 10 includes “device registration process”, “session update process”, “Mutual authentication based on PKI to creation of shared key”, “mutual authentication using shared key”. Performs "authentication to creation of information related to session”, “device history information transmission processing”, and “control information transmission processing”.
  • the controller and the device follow the connection request, mutual authentication based on PKI, mutual key generation using the shared key, and the mutual key using the shared key in steps S101 to S107 in the sequence diagram of FIG. Create information related to authentication and session, and register each controller and device.
  • the authentication processing unit 204 of the device 200a registers the connection controller management table 3100 via the device management unit 201 in step S104
  • the group key information created in step S103 is the group key (current) 3140. Is registered in the item (step S104).
  • step S106 when the device management unit 101 of the controller 100 registers the connected device management table 3000, the group key information is registered in the item of the group key (current) 3040 (step S106).
  • (Session update process) 30 and 31 are flowcharts illustrating an example of the procedure of the session update process of the present embodiment in each of the device and the controller.
  • FIG. 32 is a session update process including an exchange between the device and the controller. It is a sequence diagram which shows an example of the procedure of.
  • the device monitors the remaining session time set with the controller and confirms whether or not it is equal to or less than a predetermined value (step S4010). If the remaining session time is greater than the predetermined value (NO in step S4010), monitoring is continued.
  • the device transmits a session update request to the controller to perform session update (step S4020).
  • step S4030 After executing mutual authentication using the shared key with the controller by executing the subroutine “Mutual authentication using shared key to creating information related to session”, the group key and A session key is created and a session validity period is set (step S4030).
  • step S4030 If the return value of the subroutine in step S4030 is “normal” (YES in step S4040), the process proceeds to step S4050, and the device registers information related to the new session created in step S4030 as session update information ( Step S4050).
  • the device waits for a group key update notification from the controller (step S4060). If the group key update notification is not received (NO in step S4060), the process continues to wait until it is received.
  • the group key is updated by replacing the currently used group key with the group key newly created in step S4030 (step S4070).
  • step S4030 if the return value of the subroutine in step S4030 is “error” (NO in step S4040), the session update process is terminated without performing the session update.
  • the controller waits for a session update request from the device (step S4110). If not received (NO in step S4110), it continues to wait for a session update request from the device.
  • the controller executes the subroutine “Mutual authentication using shared key to creation of information related to session” to execute mutual subroutine using the device and the shared key. After the authentication, the group key and session key, which are information related to the session, are created, and the session valid period is set (step S4120).
  • step S4120 If the return value of the subroutine in step S4120 is “normal” (YES in step S4130), the controller registers information related to the new session created in step S4120 as session update information (step S4140).
  • step S4120 when the return value of the subroutine in step S4120 is “error” (NO in step S4130), session update is not performed for the device that is executing the session update.
  • step S4150 If there is another device that has not updated the session (YES in step S4150), the process returns to the first step and waits for a session update request from the device that has not been updated (step S4110).
  • step S4150 If the session update processing is completed for all devices (NO in step S4150), a group key update notification is transmitted to devices using the same group key (step S4160).
  • the controller itself updates the group key by exchanging the currently used group key with the group key newly created in step S4120 (step S4170).
  • the device 200a is a reference device and the device 200b is a device other than the reference device.
  • each device requests a session update for the controller according to the remaining session time, and performs mutual authentication using the shared key to create information related to the session. Then, the device and the controller register session update information.
  • step S304 and step S310 the device management unit 201 of each device registers the created session key, group key, and session valid time in the connection controller management table 3100 held in the device information holding unit 203. At this time, the created group key information is registered in the item of group key (new) 3150.
  • step S305 and step S309 the device management unit 101 of the controller registers the created session key, group key, and session valid time in the connected device management table 3000 included in the device information holding unit 102.
  • the created group key information is registered in the item of group key (new) 3050.
  • the session update state 3080 as in the above-described embodiment, the value of the session update state 3080 related to a device other than the reference device is set to “unupdated” when performing a session update with the reference device. And when updating a session with a device other than the reference device, it is updated to “updated”.
  • the device management unit 101 of the controller 100 refers to the item of the session update status 3080 in the connected device management table 3000 and confirms whether there is a device that has not been “updated”. At this time, if there is a device whose session update status item is “unupdated”, it waits for a session update request from the device. If there is no device whose session update state is “unupdated”, the device management unit 101 of the controller sends a group key update notification to all devices that perform encrypted communication using the same group key (step S311). ).
  • the device management unit 201 of the device Upon receiving the group key update notification, the device management unit 201 of the device overwrites and updates the value of the group key (current) 3140 with the value held by the group key (new) 3150 of the connection controller management table 3100, and the group key ( New) The value set in 3150 is deleted.
  • the device management unit 101 of the controller 100 also updates the group key (current) 3040 with the value held in the group key (new) 3050 of the connected device management table 3000, and sets it to the group key (new) 3050. Delete the values that are present.
  • the encryption key used for encrypting the information that the controller transmits to the device at once is the encryption key held by each of the controller and the device as a “group key (current)”.
  • the group key newly created in the session update process between the controller and each device is held in a place different from the group key used for encrypted communication.
  • the controller notifies the device of a group key update, and the controller and each device perform group key switching. This makes it possible for the controller and multiple devices to update the group key at the same timing. Even if the controller and each device perform mutual authentication and group key update, the controller Simultaneous transmission can be performed.
  • the controller and the device are connected to one network.
  • the network may be a home area network or other area network.
  • one group key is set for one controller, but a plurality of group keys may be set. At this time, one reference device is set for each device using the same group key.
  • the controller when the connection between the controller and the reference device is deleted, the controller extracts another device from the connected device management table held by the device information holding unit and sets it as the reference device.
  • the reference device may designate a device that is always turned on. For example, a device such as a refrigerator that is always turned on and operating may be specified.
  • the challenge response authentication using the shared key and the random number is performed.
  • the present invention is not limited to this.
  • the authentication method of RFC5191, Protocol for Carrying Authentication for Network Access (PANA) may be used. Since RFC 5191 uses a general technique described in Non-Patent Document 3, description thereof is omitted.
  • authentication may be further performed using EAP-PSK.
  • the session key may be derived using EMSK derived as a result of EAP-PSK negotiation.
  • HMAC_SHA2_256 may be used as the key derivation function at this time.
  • the controller creates a group key and distributes it to the device during the device registration process and the session update process.
  • the group key may be shared by exchanging keys by ECDH or DH (Diffie-Hellman) between the controller and the reference device.
  • each of the controller and the reference device generates a random number, encrypts the generated random number with a shared key, and transmits it to the other party. Then, the received encrypted random number may be decrypted with the shared key, and the result of the exclusive OR operation between the random number generated by itself and the decrypted random number may be used as the group key.
  • the controller according to the present disclosure may be a dedicated device for the controller. Moreover, the distribution board installed in a home may be sufficient. Other AV devices such as televisions may be used, and home appliances may be used.
  • the controller may have a function of displaying the power consumption of the connected device, the power of the storage battery, and the amount of power generated by solar power generation.
  • the communication method between the controller and the device according to the present disclosure may be Ethernet (registered trademark), Wi-Fi (Wireless Fidelity), specific low-power radio, power line communication, or Bluetooth (registered trademark). .
  • the device when there is an unupdated device in the session update process, the device is started to update the session by sending a session update notification to the device.
  • the controller may periodically send a session update notification to the device.
  • the device in the session update process, when there is a device that has not been updated in the session, the device is started to update the session by transmitting a session update notification to the device.
  • the device determines that the session update process cannot be started due to processing being executed in the device, the device notifies the controller of the session update postponement time, Session update processing may be performed after the postponement time has elapsed.
  • the session expiration date is managed by the remaining session time included in the connected device management table and the connection controller management table.
  • the present invention is not limited to this, and it may be managed by the session start date and time or the session end date and time.
  • a predetermined session valid period is set in advance, and the date and time when the session valid period is added to the session start date and time are compared with the current date and time to determine whether to update the session. May be.
  • the session update timing is determined based on the remaining session time, and a session update request is sent to the controller to start the session update.
  • the controller may determine the session update timing based on the remaining session time and start the session update.
  • the session key for performing one-to-one encrypted unicast communication is shared between the device and the controller. However, all of the encrypted communication between the device and the controller may be performed with the group key without sharing the session key.
  • both the group key and the session key are updated in the session update process.
  • the present invention is not limited to this, and only the group key or the session key is used during the session update process. May be updated.
  • the controller, the device, and the server which are devices related to the authentication system in the above embodiment, specifically include a processor, a memory, and the like.
  • a computer program is recorded in the memory.
  • Each device achieves its functions by the processor operating in accordance with a computer program recorded in the memory.
  • the computer program is configured by combining a plurality of instruction codes indicating instructions for the computer in order to achieve a predetermined function.
  • a part or all of the constituent elements of each device according to the authentication system in the above embodiment may be configured by one system LSI (Large Scale Integration).
  • LSI Large Scale Integration
  • Each part of the constituent elements constituting each of the above devices may be individually made into one chip, or may be made into one chip so as to include a part or all of them.
  • system LSI is described here, it may be referred to as an IC (Integrated Circuit), LSI, super LSI, or ultra LSI depending on the degree of integration. Further, the method of circuit integration is not limited to LSI's, and implementation using dedicated circuitry or general purpose processors is also possible.
  • An FPGA Field Programmable Gate Array
  • a reconfigurable processor that can reconfigure the connection and setting of circuit cells inside the LSI may be used.
  • a part or all of the constituent elements constituting each device according to the authentication system in the above embodiment may be constituted by an IC card or a single module that can be attached to and detached from each device.
  • This IC card or this module may have tamper resistance.
  • the present disclosure may be the method described above. Further, the present invention may be a computer program that realizes these methods by a computer, or may be a digital signal composed of the computer program. These computer programs may be stored in a memory and executed by a processor.
  • the present disclosure is directed to a computer-readable recording medium such as a flexible disk, hard disk, CD-ROM, MO, DVD, DVD-ROM, DVD-RAM, BD (Blu-ray (registered trademark)).
  • a computer-readable recording medium such as a flexible disk, hard disk, CD-ROM, MO, DVD, DVD-ROM, DVD-RAM, BD (Blu-ray (registered trademark)).
  • Disc or recorded in a semiconductor memory or the like.
  • the digital signal may be recorded on these recording media.
  • the computer program or the digital signal may be transmitted via an electric communication line, a wireless or wired communication line, a network represented by the Internet, a data broadcast, or the like.
  • the present disclosure may be a computer system including a processor and a memory, wherein the memory records the computer program, and the processor may operate according to the computer program.
  • the controller, the first device, and the second device share a group key, and the controller uses the group key for the first device and the second device.
  • the controller and the first device and the second device are authenticated by the controller and the first device performing mutual authentication.
  • a key is created and shared, and the first mutual authentication step of setting the first device as a reference device, the controller and the second device perform mutual authentication, and are created in the first mutual authentication step
  • the controller and the first device as the reference device are Performing a mutual authentication, updating the group key, sharing the updated group key, and a group key update timing at which the controller and the reference device update the group key.
  • a second mutual authentication step in which the controller and the second device that is not the reference device perform mutual authentication and share the updated group key with the second device.
  • the group device can be updated among multiple devices by setting the reference device from the devices connected to the controller and updating the group key by another device based on the group key update timing of the reference device.
  • the controller can perform simultaneous transmission of encrypted information even when the controller and each device perform mutual authentication and group key update.
  • the controller, the first device, and the second device may be connected to one home area network.
  • devices that do not share the updated group key receive the group key update notification from the controller and update the group key.
  • the group key update timings of a plurality of devices connected to the controller can be matched.
  • the controller and the first device in the first mutual authentication step, further set a first session period, and in the second mutual authentication step, The controller and the second device set a second session period based on the first session period and an elapsed period from the first session period setting time point, and the controller and the first device
  • the third mutual authentication step is started based on an elapsed period from the first session period setting time point and the first session period, and the group key update timing is determined based on the elapsed period from the second session period setting time point and the first The timing may be based on two session periods.
  • the session period between the controller and the device other than the reference device is set based on the remaining session period between the controller and the reference device, and each device connected to the controller updates the group key based on the session period.
  • the controller owns the private key and public key certificate of the controller itself, and the first device has the private key and public key certificate of the first device itself.
  • a first shared key sharing step in which the controller and the first device create and share a first shared key, and the mutual authentication in the first mutual authentication step is a public key infrastructure.
  • the public key authentication is performed by using the public key certificate owned by each other, and the mutual authentication in the third mutual authentication step is performed by using the first shared key. It may be authentication.
  • the controller and the first device share a first shared key by key exchange, and the shared key authentication is performed by the controller.
  • the first device may perform mutual authentication by challenge-response authentication performed using a random number created with each other and the first shared key.
  • the second device owns the private key and public key certificate of the second device, and the controller and the second device A second shared key sharing step of creating and sharing a shared key, wherein the mutual authentication in the second mutual authentication step performs mutual authentication using the public key certificates owned by each other based on a public key infrastructure It is public key authentication, and the mutual authentication in the fourth mutual authentication step may be shared key authentication in which mutual authentication is performed using the second shared key.
  • the controller reduces the processing load related to mutual authentication by performing a combination of two types of procedures: mutual authentication based on PKI and mutual authentication using a shared key with all devices connected to the controller. can do.
  • the controller, the first device, and the second device share a group key, and the controller uses the group key for the first device and the second device.
  • Authentication system that performs simultaneous transmission of encrypted information, the controller and the first device perform mutual authentication, create and share a group key, and set the first device as a reference device
  • First mutual authentication means that performs the mutual authentication between the controller and the second device, and causes the second device to share the group key created in the first mutual authentication step.
  • the controller and the first device as the reference device execute mutual authentication again, update the group key, and share the updated group key A third mutual authentication means, and at the group key update timing at which the controller and the reference device update the group key, the controller and the second device that is not the reference device perform mutual authentication, and the update And a fourth mutual authentication unit for sharing a later group key with the second device.
  • the group device can be updated among multiple devices by setting the reference device from the devices connected to the controller and updating the group key by another device based on the group key update timing of the reference device.
  • the controller can perform simultaneous transmission of encrypted information even when the controller and each device perform mutual authentication and group key update.
  • the authentication method according to the present disclosure is used for mutual authentication between the controller and each device, group key update, etc. in a network system that performs simultaneous transmission of information encrypted using a group key to multiple devices connected to the controller. can do.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Computing Systems (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Power Engineering (AREA)
  • Small-Scale Networks (AREA)

Abstract

コントローラと第１機器とは相互認証を実行し、グループ鍵を作成して共有すると共に、第１機器を基準機器として設定する。その後、コントローラと基準機器とがグループ鍵を更新するグループ鍵更新タイミングにおいて、コントローラと基準機器ではない第２機器とが相互認証を実行し、更新後のグループ鍵を第２機器にも共有させる。また、グループ鍵を用いて送信データを暗号化して暗号化データを生成し、送信データと、ヘッダと、送信元アドレスと、送信先アドレスとからＭＡＣを生成し、暗号化データと、ヘッダと、送信元アドレスと、送信先アドレスと、ＭＡＣとを含むメッセージの一斉同報通信を行う。

Description

認証方法及び認証システム
　本開示は、エリアネットワークに接続する機器を認証する技術に関し、特に、コントローラと機器との間で相互認証しグループ鍵を更新する技術に関する。
　近年、ネットワーク接続機能を有する家電機器やＡＶ機器、住宅設備機器などの機器類（以下、単に「機器」と呼ぶ。）からクラウドサーバに収集される各種履歴情報を用いたサービスが期待されている。家庭内に設置されている機器同士を接続することで形成されるネットワークを、以下ではホームエリアネットワークと呼ぶ。
　このようなホームエリアネットワークに特定の機器（以下、「コントローラ」と呼ぶ。）を接続し、機器と外部のサーバとの間の通信を、コントローラを介して行う場合がある。そこで、コントローラと各機器との接続を安全に設定することで家庭内の通信を制御し、不正機器のなりすましによる接続や通信内容の傍受による情報漏洩などを防止することが求められる。例えば、前者に対しては接続機器の認証、後者に対しては通信の暗号化などの対策が考えられ、正当性が認証されたコントローラと機器とは暗号鍵を共有し、当該暗号鍵を用いた暗号通信を行う。コントローラと接続する機器が複数存在する場合、コントローラと当該機器とが同一の暗号鍵（以下、「グループ鍵」と呼ぶ。）を共有することで、コントローラが複数機器に対して同一情報を一斉送信するマルチキャスト通信やブロードキャスト通信の暗号化が行われる。
ＮＳＡ　Ｓｕｉｔｅ　Ｂ　Ｉｍｐｌｅｍｅｎｔｅｒ‘ｓ　Ｇｕｉｄｅ　ｔｏ　ＦＩＰＳ　１８６－４　（ＥＣＤＳＡ） ＮＩＳＴ　Ｓｐｅｃｉａｌ　Ｐｕｂｌｉｃａｔｉｏｎ　８００－５６Ａ　Ｒｅｖｉｓｉｏｎ　２ ＲＦＣ５１９１　Ｐｒｏｔｏｃｏｌ　ｆｏｒ　Ｃａｒｒｙｉｎｇ　Ａｕｔｈｅｎｔｉｃａｔｉｏｎ　ｆｏｒ　Ｎｅｔｗｏｒｋ　Ａｃｃｅｓｓ（ＰＡＮＡ）
　上記、従来の認証システムでは、グループ鍵に関する更なる改善が必要とされていた。
　コントローラと第１機器と第２機器とがグループ鍵を共有し、前記コントローラが前記第１機器と前記第２機器とに対して、前記グループ鍵を用いて暗号化した情報の一斉同報通信を行う認証システムにおける、前記コントローラと前記第１機器及び前記第２機器との認証方法であって、前記コントローラと前記第１機器とが相互認証を実行し、グループ鍵を作成して共有すると共に、前記第１機器を基準機器として設定する第１相互認証ステップと、前記コントローラと前記第２機器とが相互認証を実行し、前記第１相互認証ステップで作成したグループ鍵を前記第２機器にも共有させる第２相互認証ステップと、前記第２相互認証ステップの後に、前記コントローラと前記基準機器である前記第１機器とが再び相互認証を実行し、前記グループ鍵を更新し、更新後のグループ鍵を共有する第３相互認証ステップと、前記コントローラと前記基準機器とが前記グループ鍵を更新するグループ鍵更新タイミングにおいて、前記コントローラと前記基準機器ではない前記第２機器とが相互認証を実行し、前記更新後のグループ鍵を前記第２機器にも共有させる第４相互認証ステップと、前記グループ鍵を用いて送信データを暗号化して暗号化データを生成し、当該送信データと、ヘッダと、送信元アドレスと、送信先アドレスとからＭＡＣを生成し、当該暗号化データと、当該ヘッダと、当該送信元アドレスと、当該送信先アドレスと、当該ＭＡＣとを含むメッセージの前記一斉同報通信を行う暗号化ステップとを含むことを特徴とする。
　なお、これらの包括的または具体的な態様は、システム、装置、集積回路、コンピュータプログラム、または、記録媒体で実現されてもよく、システム、装置、方法、集積回路、コンピュータプログラムおよび記録媒体の任意な組み合わせで実現されてもよい。
　本開示によれば、認証システムにおけるグループ鍵に関する更なる改善を実現できる。
図１は、認証システム１０のシステム構成を示す概略図である。 図２は、コントローラ１００の主要部の機能ブロック図である。 図３は、接続機器管理テーブル１０００のデータ構造とデータの一例を示す図である。 図４は、公開鍵証明書のデータ構成の一例を示す図である。 図５は、ＣＲＬのデータ構成の一例を示す図である。 図６は、機器２００ａの主要部の機能ブロック図である。 図７は、接続コントローラ管理テーブル１１００のデータ構造とデータの一例を示す図である。 図８は、サーバ３００の主要部の機能ブロック図である。 図９は、機器情報管理テーブル１３００のデータ構造とデータの一例を示す図である。 図１０は、機器における機器登録処理の手順の一例を示したフローチャートである。 図１１は、コントローラにおける機器登録処理の手順の一例を示したフローチャートである。 図１２は、機器登録処理の手順の一例を示したシーケンス図である。 図１３は、機器におけるセッション更新処理の手順の一例を示したフローチャートである。 図１４は、コントローラにおけるセッション更新処理の手順の一例を示したフローチャートである。 図１５は、セッション更新処理の手順の一例を示したシーケンス図である。 図１６は、機器におけるＰＫＩに基づく相互認証～共有鍵の作成の手順の一例を示したフローチャートである。 図１７は、コントローラにおけるＰＫＩに基づく相互認証～共有鍵の作成の手順の一例を示したフローチャートである。 図１８は、ＰＫＩに基づく相互認証～共有鍵の作成の手順の一例を示したシーケンス図である。 図１９は、機器における共有鍵を用いた相互認証～セッションに係る情報の作成の手順の一例を示したフローチャートである。 図２０は、コントローラにおける共有鍵を用いた相互認証～セッションに係る情報の作成の手順の一例を示したフローチャートである。 図２１は、共有鍵を用いた相互認証～セッションに係る情報の作成の手順の一例を示したシーケンス図である。 図２２は、機器履歴情報送信処理の手順の一例を示したシーケンス図である。 図２３は、制御情報送信処理の手順の一例を示したシーケンス図である。 図２４は、暗号化前と暗号化後のメッセージフォーマットのデータ構成図である。 図２５は、機器履歴情報ＭＡＣ送信処理の手順の一例を示したシーケンス図である。 図２６は、制御情報ＭＡＣ送信処理の手順の一例を示したシーケンス図である。 図２７は、実施の形態２に係る接続機器管理テーブル２０００のデータ構造とデータの一例を示す図である。 図２８は、実施の形態２に係る機器におけるセッション更新処理の手順の一例を示したフローチャートである。 図２９は、実施の形態２に係るコントローラにおけるセッション更新処理の手順の一例を示したフローチャートである。 図３０は、実施の形態２に係るセッション更新処理の手順の一例を示したシーケンス図である。 図３１は、実施の形態３に係る接続機器管理テーブル３０００のデータ構造とデータの一例を示す図である。 図３２は、実施の形態３に係る接続コントローラ管理テーブル３１００のデータ構造とデータの一例を示す図である。 図３３は、実施の形態３に係る機器におけるセッション更新処理の手順の一例を示したフローチャートである。 図３４は、実施の形態３に係るコントローラにおけるセッション更新処理の手順の一例を示したフローチャートである。 図３５は、実施の形態３に係るセッション更新処理の手順の一例を示したシーケンス図である。
　（本開示の基礎となった知見）
　機器とコントローラとの間のセキュリティを保持するためには、接続時に相互認証を行って以降、同じグループ鍵を使い続けるのではなく、機器とコントローラとが改めて相互認証を行い、グループ鍵を更新することが望まれる。
　しかしながら、それぞれの機器がそれぞれのタイミングでグループ鍵の更新を行うと、各機器が異なるグループ鍵を保持することになる。例えば、一の機器は更新後のグループ鍵を保持しているが、二の機器は更新前のグループ鍵を保持しているような場合、コントローラはグループ鍵を用いた暗号化情報の一斉送信を行うことができない。
　本開示は係る課題に鑑みてなされたものであり、各機器とコントローラとの間におけるグループ鍵の更新タイミングを合わせることができる認証方法を提供するものである。
　本開示の一態様に係る認証方法は、コントローラに接続する機器の中から基準機器を設定し、当該基準機器におけるグループ鍵更新のタイミングに基づき、他の機器がグループ鍵の更新を行うことで、複数の機器間におけるグループ鍵更新のタイミングを合わせることが可能となる。
　これにより、コントローラと各機器とが相互認証及びグループ鍵更新を行っても、コントローラは暗号化した情報の一斉送信を行うことができる。
　以下図面を参照しながら、本開示の実施の形態について説明する。なお、以下の実施の形態は、本開示を具体化した一例であって、本開示の技術的範囲を限定するものではない。
　＜１．実施形態１＞
　＜１－１．概要＞
　以下、本開示に係る認証方法を用いた一実施形態としての認証システム１０について、図を用いながら説明する。
　図１は、本実施の形態に係る認証システム１０のシステム構成の一例を示す概略図である。
　認証システム１０は、ホームエリアネットワーク４００に接続するコントローラ１００及び機器２００ａ、機器２００ｂ、機器２００ｃを含む構成である。認証システム１０におけるコントローラ１００は、インターネットなどの通信網であるネットワーク５００を介して、サーバ３００と接続する。
　コントローラ１００及び機器２００ａ～機器２００ｃは、１つのホームエリアネットワーク４００に接続する。図には示していないが、ネットワーク機器（例えば、ハブ、ルータ等）を介して接続してもよい。また、コントローラ１００または各機器を設置する場所は、屋内及び屋外を問わない。
　コントローラ１００と機器２００ａ～機器２００ｃのそれぞれとは、接続を開始する際に相互認証を行う。そして、相互認証の結果、互いの正当性が確認できた場合は暗号鍵を共有し暗号通信を行う。コントローラと各機器とは、以降、それぞれの所定のタイミングでセッション更新処理を行い、セッション更新処理の都度、相互認証を行い、その結果が正当である場合に暗号鍵を更新し、暗号通信を継続する。
　このようなコントローラ１００と各機器とは、接続時の相互認証において互いの正当性を確認した後、３種類の共有鍵を共有する。
　一の共有鍵は、コントローラ１００とそれぞれの機器との間において、セッション更新処理時の相互認証に用いる共有鍵である。コントローラと機器とが接続する際には、まず、公開鍵認証基盤（ＰＫＩ：Ｐｕｂｌｉｃ　Ｋｅｙ　Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）に基づく相互認証を行う。一方、当該ＰＫＩによる相互認証以降、セッション更新処理時において、コントローラと機器とが行う相互認証は、当該一の共有鍵を用いて行う。以下、単に、「共有鍵」と記述している場合、当該相互認証に用いる共有鍵を示すものとする。ただし、明らかに、以下で説明するグループ鍵及びセッション鍵を示す記載をしている場合は除く。
　コントローラと機器との間の暗号通信には、共有鍵暗号方式を用いるため、コントローラと機器とは共有鍵を共有する。
　二の共有鍵と三の共有鍵とは、この暗号通信に用いるための共有鍵であり、それぞれを、グループ鍵とセッション鍵と呼ぶ。グループ鍵は、コントローラが複数機器に対して同一情報を一斉送信するために使用する暗号鍵であり、コントローラは、コントローラに接続する全ての機器と同一のグループ鍵を共有する。セッション鍵は、コントローラと各機器とが１対１のユニキャスト通信を行うために使用する暗号鍵であり、コントローラは、それぞれの機器との間で、個別の暗号鍵を共有する。
　ここで、コントローラと各機器との間の通信には、セッション有効期間を設けるものとし、グループ鍵及びセッション鍵は、当該セッション有効期間において利用可能とする。セッションを設定して以降、セッション有効期間を超過した場合は、グループ鍵及びセッション鍵を利用不可とするように制御する。なお、セッション有効期間経過後も暗号通信を継続するためには、コントローラとそれぞれの機器との間でセッション更新処理を行い、新たなグループ鍵及びセッション鍵を作成し、新たなセッションを設定する必要がある。
　また、コントローラは、接続する複数機器のうちの１つの機器を、基準機器として設定する。そして、コントローラ１００と各々の機器とがグループ鍵を更新するタイミングは、基準機器がセッション更新処理を行い、グループ鍵を更新するタイミングに基づくものとし、具体的な方法は後述する。なお、基準機器は、例えば、コントローラ１００が最初に接続する機器とする。
　サーバ３００は、機器２００ａ～機器２００ｃに対して、サービス提供などを行う外部のサーバである。サーバ３００と各機器とが通信する際には、コントローラ１００を介して行う。
　例えば、各機器は、機器の動作を示す機器履歴情報を、コントローラ１００を介して、サーバ３００に送信する。また、サーバ３００は、コントローラ１００を介して、それぞれの機器にサービス情報を送信する。ここでは、サーバ３００は、各機器に所定の機能を実行させるための制御依頼情報を送信するものとする。コントローラ１００は、当該制御依頼情報を受信して解読し、各機器に実行させるための制御コマンドを作成して送信する。そして、当該制御コマンドを受信したそれぞれの機器は、サーバ３００から依頼された機能を実行する。
　＜１－２．構成＞
　本実施の形態に係る認証システム１０の主要な構成要素であるコントローラ１００及び機器２００ａ～機器２００ｃと、当該認証システム１０に接続するサーバ３００の各構成について、以下、図を用いながら説明する。
　＜１－２－１．コントローラ１００＞
　図２は、コントローラ１００の主要部の機能ブロック図であり、コントローラ１００は、機器管理部１０１、機器情報保持部１０２、認証処理部１０３、認証情報保持部１０４、通信部１０５を含む構成である。また、コントローラ１００は、図示してはいないが、プロセッサ及びメモリを含む構成であり、機器管理部１０１、機器情報保持部１０２、認証処理部１０３、認証情報保持部１０４、通信部１０５の各機能は、メモリに記憶されているプログラムをプロセッサが実行することにより実現される。機器情報保持部１０２、認証情報保持部１０４における各データの保持は、メモリによって実現される。
　（機器管理部１０１）
　機器管理部１０１は、コントローラ１００と機器２００ａ～機器２００ｃとの接続を制御するために、次のような機能を有する。
　機器管理部１０１は、コントローラ１００に対する、機器からの接続要求やセッション更新要求を、通信部１０５を介して受付ける。そして、当該機器との間の相互認証処理を、認証処理部１０３に実行させる。
　機器管理部１０１は、認証処理部１０３にて行われた認証処理の結果、当該機器の正当性が認められた場合、機器情報保持部１０２で保持する接続機器管理テーブル１０００に接続機器管理データを登録する。接続機器管理テーブル１０００が保持する接続機器管理データの詳細については後述する。
　機器管理部１０１は、基準機器の設定を行う。例えば、コントローラ１００と最初に接続する機器を基準機器として設定してもよい。また、基準機器として登録されている機器との接続が切断された場合、機器情報保持部１０２の保持する接続機器管理テーブル１０００から、別の機器を抽出して基準機器として設定する。このとき、電源が常時ＯＮである機器を基準機器として設定してもよい。機器管理部１０１は、当該基準機器の設定についても、接続機器管理テーブル１０００に登録する。機器との接続時においては、当該機器を基準機器として設定するか否かの判断を、認証処理部１０３が行い、その判断結果を受けて、機器管理部１０１が接続機器管理テーブル１０００に登録する。
　機器管理部１０１は、接続機器管理テーブル１０００の項目であるセッション更新状態を参照し、セッションが未更新である機器に対して、通信部１０５を介して、セッション更新通知を行う。当該セッション更新通知は、機器に対してセッション更新を促すためのものであり、その後、改めて、機器側からのコントローラ１００に対するセッション更新要求を受付けることで、セッションを更新する。
　機器管理部１０１は、接続機器管理テーブル１０００の項目であるセッション残り時間の値を参照し、セッションが更新されないままセッション有効期間を超過した機器、すなわちセッション残り時間がゼロである機器に対して、当該機器との間で保持する、グループ鍵やセッション鍵などの暗号鍵の情報を削除することで、当該機器との暗号通信を禁止する。
　また、機器管理部１０１は、機器２００ａ～機器２００ｃより、通信部１０５を介して受信する、暗号化された機器履歴情報を復号する。復号した機器履歴情報は、通信部１０５を介して、サーバ３００に送信する。
　さらに、機器管理部１０１は、サーバ３００より、通信部１０５を介して受信する、機器の制御依頼情報を機器に指示可能な形式に加工した後、グループ鍵またはセッション鍵にて暗号化し、通信部１０５を介して、機器に送信する。
　（機器情報保持部１０２）
　機器情報保持部１０２は、コントローラ１００に接続する機器２００ａ～機器２００ｃの情報を保持する。図３は、機器情報保持部１０２が、機器の情報を管理するために保持する、接続機器管理テーブル１０００のデータ構造とデータの一例を示す図である。
　接続機器管理テーブル１０００は、機器毎の接続機器管理レコード群からなる。接続機器管理レコードは、機器とコントローラとが接続する際に行う機器登録処理において、機器が正当な機器であると認められた場合に登録するデータであり、機器ＩＤ１０１０、証明書ＩＤ１０２０、共有鍵１０３０、グループ鍵１０４０、セッション鍵１０５０、セッション残り時間１０６０、セッション更新状態１０７０、基準機器１０８０の項目が含まれる。
　図３のデータの例示を用いながら、各項目について説明する。
　機器ＩＤ１０１０は、機器を一意に定める識別子である。
　証明書ＩＤ１０２０は、機器の公開鍵証明書の証明書ＩＤである。
　共有鍵１０３０は、コントローラ１００と機器との間で共有する共有鍵のデータである。
　グループ鍵１０４０は、コントローラ１００が複数機器に対して一斉送信する情報の暗号化に用いるグループ鍵のデータである。図３は、コントローラに接続する全ての機器である機器ＩＤ１～機器ＩＤ３と、同一のグループ鍵“１１２２３・・・”を共有していることを示している。なお、図３の例示では、機器ＩＤ１～機器ＩＤ３が、１つのグループ鍵の項目欄を共有する例を示しているが、機器ＩＤごとに個別の項目欄を有し、当該項目を登録する際に、基準機器以外の機器は、基準機器と同じグループ鍵のデータを設定するとしてもよい。
　セッション鍵１０５０は、コントローラ１００と機器との間のユニキャスト通信を暗号化するために用いるセッション鍵のデータである。図３の例でも、コントローラは、機器ＩＤ１～機器ＩＤ３の各機器との間で、それぞれ別のセッション鍵を共有していることを示している。
　セッション残り時間１０６０は、コントローラ１００と機器との間で設定するセッション有効期間の残余期間である。コントローラ１００と機器との間には、予め定めた所定のセッション有効期間を設ける。セッションを設定あるいは更新する都度、セッション残り時間１０６０には、セッション有効期間を登録する。以降、時間の経過とともに、当該項目の値をカウントダウンさせることで、セッション残り時間１０６０はセッション有効期間の残余期間を表す。
　なお、セッション残り時間がゼロになった機器は、機器管理部１０１により、当該機器との間で保持するグループ鍵、セッション鍵の情報が削除され、暗号通信が禁止される。
　セッション更新状態１０７０は、コントローラ１００と基準機器との間でセッション更新を行って以降の期間において、機器ＩＤが示す機器がコントローラ１００とのセッション更新を行ったか否かを示すデータである。コントローラ１００が基準機器とのセッション更新を行った時点で、基準機器以外の機器に係るセッション更新状態１０７０を“未更新”に更新する。その後、コントローラ１００が当該機器とのセッション更新処理を行った時点で、セッション更新状態１０７０を“更新済”に更新する。
　基準機器１０８０の項目は、機器が基準機器であるか否かを示すデータである。
　セッション更新状態１０７０及び基準機器１０８０の項目について、図３の例示では、機器ＩＤ１の機器が基準機器であることを示している。また、コントローラ１００と基準機器である機器ＩＤ１の機器とがセッション更新を行った以降において、コントローラは、機器ＩＤ２の機器とは既にセッションを更新した状態であり、機器ＩＤ３の機器とはセッションが未更新であることを表している。
　（認証処理部１０３）
　認証処理部１０３は、コントローラ１００と接続する機器との相互認証処理を行う機能を有する。機器との接続時においては、ＰＫＩに基づく相互認証を行い、セッション更新時においては、共有鍵と乱数とを用いたチャレンジレスポンス認証による相互認証を行う。
　認証処理部１０３は、機器管理部１０１から、機器の認証依頼とともに当該機器の公開鍵証明書を受け付け、ＰＫＩに基づく認証処理を行う。具体的には、まず、認証情報保持部１０４に格納されているＣＲＬ（Ｃｅｒｔｉｆｉｃａｔｅ　Ｒｅｖｏｃａｔｉｏｎ　Ｌｉｓｔ）に基づき、取得した機器の公開鍵証明書に係る証明書ＩＤがＣＲＬに記載されていないことを確認する。そして、公開鍵証明書に付されている署名を認証局の公開鍵を用いて検証する。ここでは、認証局はサーバ３００とする。
　また、認証処理部１０３は、コントローラ１００と機器との間でセッション更新を行う際、共有鍵を用いた相互認証であるチャレンジレスポンス認証を行う。認証処理部１０３は、機器との間で、鍵交換により当該共有鍵を作成する機能も有する。認証処理部１０３は乱数を生成し、通信部１０５を介して、機器に送信する。そして、機器が共有鍵で暗号化して返送した乱数を、コントローラが保持する共有鍵で復号し、自身が作成した乱数と照合することで機器の正当性を確認する。また、同様に、認証処理部１０３が、機器から受信した乱数を共有鍵で暗号化して返送することで、機器側での検証も行われる。
　さらに、認証処理部１０３は、セッションの設定及び更新に必要な処理を実行する機能を有する。具体的には、コントローラ１００と機器との通信を暗号化するための共有鍵である、グループ鍵とセッション鍵とを作成する。また、セッション有効期間を設定し、セッション鍵及びグループ鍵とともに、機器管理部１０１を介して、機器情報保持部１０２が保持する接続機器管理テーブル１０００に登録する。
　（認証情報保持部１０４）
　認証情報保持部１０４は、コントローラ１００自身の秘密鍵と公開鍵証明書とを保持する。また、ＰＫＩに基づく相互認証において、相手機器の公開鍵証明書が失効していないことを確認するために使用するＣＲＬを保持している。このような、秘密鍵と公開鍵証明書とＣＲＬとは、コントローラ１００の製造時に埋め込むものとする。
　図４は、公開鍵証明書の標準的なデータ構成例である公開鍵証明書１５００のデータ構成を示す図である。公開鍵証明書１５００は、当該証明書に係るバージョン１５１０、発行者１５２０、有効期間の開始１５３０、有効期間の終了１５４０、証明書ＩＤ１５５０、公開鍵１５６０、認証局であるサーバ３００の署名１５７０を含む構成である。ここで、公開鍵１５６０はコントローラ自身の公開鍵のデータであり、署名１５７０は認証局の秘密鍵を用いて作成して付与された署名である。
　図５は、ＣＲＬの標準的なデータ構成例であるＣＲＬ１６００を示す図である。ＣＲＬ１６００は、当該ＣＲＬに係るＣＲＬバージョン１６１０、発行者１６２０、発行日１６３０、次回発行日１６４０、失効した証明書ＩＤ１６５０、認証局であるサーバの署名１６６０を含む構成である。ここで、失効した証明書ＩＤ１６５０は、１つのＩＤに限定するわけではなく、複数の失効した証明書ＩＤを保持してもよい。また、署名１６６０は認証局の秘密鍵を用いて作成して付与された署名である。
　（通信部１０５）
　通信部１０５は、コントローラ１００が、機器２００ａ～機器２００ｃ及びサーバ３００のそれぞれと接続するための通信インターフェイスである。例えば、機器情報保持部１０２の接続機器管理テーブル１０００に保持するセッション鍵及びグループ鍵を用いて、機器２００ａ～機器２００ｃと暗号通信を行う機能を有する。
　また、通信部１０５は、サーバ３００と暗号通信を行う機能を有しており、例えば、ＳＳＬ（Ｓｅｃｕｒｅ　Ｓｏｃｋｅｔ　Ｌａｙｅｒ）通信を行う。ここで、ＳＳＬ通信に必要であるＳＳＬサーバ証明書は、通信部１０５で保持する。
　＜１－２－２．機器２００ａ＞
　機器２００ａ～機器２００ｃは、ネットワークに接続する機能を有する家電機器やＡＶ機器及び住宅設備機器であり、具体的には、例えば、テレビ、レコーダ、エアコン、冷蔵庫、蓄電池などである。
　以下、機器の構成については、代表として機器２００ａを用いて説明する。なお、各機器はそれぞれ固有の機能を有し、その点において、機器が別種の機器であれば他の機器とは共通しない。例えば、洗濯機であれば洗濯機能、エアコンであれば暖房や冷房などの機能のことであり、一般的な機能であるため説明は省略する。本願の発明である認証方法に係る機能についてのみ説明を行い、この点については、機器２００ａに限らず、他の機器も同じ機能を有することは言うまでもない。
　図６は、機器２００ａの主要部の機能ブロック図であり、機器２００ａは、機器管理部２０１、機器履歴保持部２０２、機器情報保持部２０３、認証処理部２０４、認証情報保持部２０５、通信部２０６を含む構成である。また、機器２００ａは、図示してはいないが、プロセッサ及びメモリを含む構成であり、機器管理部２０１、機器履歴保持部２０２、機器情報保持部２０３、認証処理部２０４、認証情報保持部２０５、通信部２０６の各機能は、メモリに記憶されているプログラムをプロセッサが実行することにより実現される。機器履歴保持部２０２、機器情報保持部２０３、認証情報保持部２０５における各データの保持は、メモリによって実現される。
　（機器管理部２０１）
　機器管理部２０１は、コントローラ１００との接続を制御する。具体的には次のような機能を有する。
　機器管理部２０１は、コントローラ１００に接続する際、通信部２０６を介して、接続要求をコントローラ１００に送信する。
　また、機器管理部２０１は、コントローラ１００の公開鍵証明書を、通信部２０６を介して受信すると、認証処理部２０４にＰＫＩに基づく認証処理を実行させる。
　機器管理部２０１は、認証処理部２０４にて行われた認証処理の結果、コントローラ１００の正当性が認められた場合、機器情報保持部２０３で保持する接続コントローラ管理テーブル１１００に、接続コントローラデータを登録する。接続コントローラ管理テーブル１１００が保持する接続コントローラデータの詳細については後述する。
　また、機器履歴保持部２０２に記録されている機器の動作履歴に係る機器履歴情報をセッション鍵で暗号化し、通信部２０６を介してコントローラ１００に送信する。このような機器の動作に係る機器履歴情報の送信は、定期的または非定期的に行い、コントローラ１００を経由してサーバ３００に送信される。
　さらに、機器管理部２０１は、機器情報保持部２０３の接続コントローラ管理テーブルが保持するセッション残り時間の項目を参照し、セッション残り時間の値が事前に定めた所定の閾値以下となった時点で、セッション更新を開始する。所定の閾値は、例えば、セッション有効期間の１０％の値、または、セッション更新処理に必要な時間の２倍の値などとする。ただし、機器管理部２０１が、コントローラ１００からのセッション更新通知を受信した場合には、当該セッション残り時間の値に関わらず、セッション更新を開始する。
　セッション更新を開始すると、機器管理部２０１は、認証処理部２０４に処理を実行させる。その後、認証処理部２０４が作成した、グループ鍵、セッション鍵、セッション有効期間を受け取り、機器情報保持部２０３で保持する接続コントローラ管理テーブル１１００に登録する。
　（機器履歴保持部２０２）
　機器履歴保持部２０２は、機器２００ａの動作を機器履歴情報として記録し、保持する機能を有する。機器履歴保持部２０２は、機器２００ａが操作されたり、機能を実行したりする都度、これらの動作を示す情報を機器履歴情報として記録する。なお、機器履歴情報は、機器２００ａがコントローラ１００を介して、サーバ３００に送信する情報の一例として示すものであるものの、本願の発明の主たる構成要素ではないため、データ項目等の詳細な説明は省略する。
　（機器情報保持部２０３）
　機器情報保持部２０３は、機器２００ａに接続するコントローラ１００の情報を保持する。図７は、機器情報保持部２０３が、コントローラの情報を管理するために保持する、接続コントローラ管理テーブル１１００のデータ構造とデータの一例を示す図である。
　接続コントローラ管理テーブル１１００は、接続コントローラ管理レコード群からなる。接続コントローラ管理レコードは、機器とコントローラとが接続する際に行う機器登録処理において、コントローラが正当な機器であると認められた場合に登録するデータであり、コントローラＩＤ１１１０、証明書ＩＤ１１２０、共有鍵１１３０、グループ鍵１１４０、セッション鍵１１５０、セッション残り時間１１６０の項目が含まれる。
　図７の例を用いながら、各項目について説明する。
　コントローラＩＤ１１１０は、コントローラを一意に定める識別子である。
　証明書ＩＤ１１２０は、コントローラの公開鍵証明書の証明書ＩＤである。
　共有鍵１１３０は、機器２００ａがコントローラ１００との間で共有する共有鍵のデータである。
　グループ鍵１１４０は、コントローラ１００が機器に対して一斉送信する情報を暗号化するために用いる共有鍵のデータである。機器側では、受信した情報を当該グループ鍵を用いて復号する。
　セッション鍵１１５０は、コントローラ１００との暗号化ユニキャスト通信を行うために用いる共有鍵のデータである。
　セッション残り時間１１６０は、コントローラ１００との間で設定するセッション有効期間の残余期間である。機器２００ａとコントローラ１００との間には、予め定めた所定のセッション有効期間を設ける。セッションを設定あるいは更新する都度、セッション有効期間をセッション残り時間１１６０に登録する。以降、時間の経過とともに、当該項目の値をカウントダウンさせることで、セッション残り時間１１６０はセッション有効期間の残余期間を表す。
　（認証処理部２０４）
　認証処理部２０４は、コントローラ１００との相互認証処理を行う機能を有する。コントローラとの接続時においては、ＰＫＩに基づく相互認証を行い、セッション更新時においては、共有鍵と乱数とを用いたチャレンジレスポンス認証による相互認証を行う。
　機器管理部２０１から、コントローラの認証依頼とともに当該コントローラの公開鍵証明書を受け付け、ＰＫＩに基づく認証処理を行う。具体的には、まず、認証情報保持部２０５に格納されているＣＲＬに基づき、取得したコントローラの公開鍵証明書の証明書ＩＤがＣＲＬに記載されていないことを確認する。また、公開鍵証明書の署名を認証局の公開鍵を用いて検証する。ここでは、認証局はサーバ３００とする。
　また、認証処理部２０４は、コントローラ１００との間で、セッション更新を行う際、共有鍵を用いた相互認証であるチャレンジレスポンス認証を行う。認証処理部２０４は、コントローラ１００との間で、鍵交換により当該共有鍵を作成する機能も有する。認証処理部２０４は乱数を生成し、通信部２０６を介して、コントローラ１００に送信する。そして、認証処理部２０４は、コントローラ１００が共有鍵で暗号化して返送した乱数を、機器が保持する共有鍵で復号し、自身が作成した乱数と照合することでコントローラの正当性を確認する。また、同様に、認証処理部２０４が、機器から受信した乱数を共有鍵で暗号化して返送することで、機器側での検証も行われる。
　さらに、認証処理部２０４は、セッションの作成及び更新に必要な処理を実行する機能を有する。具体的には、セッション更新処理の開始を、機器管理部２０１から受け付けると、通信部２０６を介して、セッション更新要求をコントローラ１００に対して送信する。また、認証処理部２０４は、通信部２０６を介して、コントローラ１００から、更新後のセッション鍵とグループ鍵とセッション有効期間とを受信し、機器管理部２０１を介して、機器情報保持部２０３が保持する接続コントローラ管理テーブル１１００に登録する。
　（認証情報保持部２０５）
　認証情報保持部２０５は、機器２００ａ自身の秘密鍵と公開鍵証明書とを保持する。また、ＰＫＩに基づく相互認証において公開鍵証明書が失効していないことを確認するために使用するＣＲＬを保持している。このような、秘密鍵と公開鍵証明書とＣＲＬとは、機器の製造時に埋め込むものとする。
　ＣＲＬ及び公開鍵証明書のデータ構成は、コントローラ１００の認証情報保持部１０４が保持するものと同様のため説明は省略する。ただし、機器２００ａの公開鍵証明書が保持する公開鍵は、機器２００ａの公開鍵であることは勿論である。
　（通信部２０６）
　通信部２０６は、コントローラ１００と接続するための通信インターフェイスである。例えば、機器情報保持部２０３の接続コントローラ管理テーブル１１００が保持するセッション鍵及びグループ鍵を用いて、コントローラ１００との間で暗号通信を行う機能を有する。
　＜１－２－３．サーバ３００＞
　図８は、サーバ３００の主要部の機能ブロック図であり、サーバ３００は、機器情報管理部３０１、機器情報保持部３０２、ＣＲＬ管理部３０３、ＣＲＬ保持部３０４、通信部３０５を含む構成である。また、サーバ３００は、図示してはいないが、プロセッサ及びメモリを含む構成であり、機器情報管理部３０１、機器情報保持部３０２、ＣＲＬ管理部３０３、ＣＲＬ保持部３０４、通信部３０５の各機能は、メモリに記憶されているプログラムをプロセッサが実行することにより実現される。機器情報保持部３０２、ＣＲＬ保持部３０４における各データの保持は、メモリによって実現される。
　（機器情報管理部３０１）
　機器情報管理部３０１は、機器情報保持部３０２を制御し、サーバ３００に接続するコントローラの情報を、コントローラに接続する機器情報を含めて管理するために、以下の機能を有する。
　機器情報管理部３０１は、通信部３０５を介して、コントローラより受信したコントローラ及び機器の情報を機器情報保持部３０２が保持する機器情報管理テーブル１３００に登録する。
　また、コントローラから、コントローラと機器との相互認証において、正当でないと判断された機器の情報を受信した場合には、当該機器の公開鍵証明書の証明書ＩＤをＣＲＬ管理部３０３に通知する。
　（機器情報保持部３０２）
　機器情報保持部３０２は、サーバ３００に接続するコントローラ及び機器の情報を保持しており、図９は、機器情報保持部３０２が有する、機器情報管理テーブル１３００のデータ構造とデータの一例を示す図である。
　機器情報管理テーブル１３００には、コントローラに係るコントローラＩＤ１３１０及び証明書ＩＤ１３２０の項目が含まれる。また、コントローラと接続する機器に係る機器ＩＤ１３３０、証明書ＩＤ１３４０、機器履歴情報１３５０の項目が含まれる。図９の例を用いながら、各項目について説明する。
　コントローラＩＤ１３１０は、コントローラを一意に定める識別子である。
　コントローラの証明書ＩＤ１３２０は、コントローラの公開鍵証明書の証明書ＩＤである。
　機器ＩＤ１３３０は、コントローラに接続する機器を識別する機器ＩＤである。図９の例では、コントローラＩＤ１で識別されるコントローラには、機器ＩＤ１、機器ＩＤ２、機器ＩＤ３で識別される３つの機器が接続していることを表している。
　機器の証明書ＩＤ１３４０は、機器の公開鍵証明証の証明書ＩＤである。
　機器履歴情報１３５０は、機器から収集した機器履歴情報のデータである。ここで、機器履歴情報そのものは、別のテーブルで機器毎に保持し、当該機器履歴情報１３５０の項目には、前記別テーブルへのリンク情報を保持するとしてもよい。
　（ＣＲＬ管理部３０３）
　ＣＲＬ管理部３０３は、機器情報管理部３０１から不正な機器の公開鍵証明書の証明書ＩＤを受付けると、ＣＲＬを発行する。
　また、ＣＲＬ管理部３０３は、サーバ３００の公開鍵と秘密鍵とを保持している。
　ＣＲＬ管理部３０３は、ＣＲＬを発行する際、サーバ３００の秘密鍵を用いて作成した署名を、ＣＲＬに付与する。当該ＣＲＬを使用する、コントローラ及び機器は、ＣＲＬに付された署名を、サーバ３００の公開鍵を用いて検証することにより、ＣＲＬが正当であることを確認する。
　ＣＲＬ管理部が発行したＣＲＬは、通信部３０５を介して、コントローラ及び機器に送信する。
　（ＣＲＬ保持部３０４）
　ＣＲＬ保持部３０４は、ＣＲＬ管理部３０３が発行したＣＲＬを保持する。ＣＲＬのデータ構成は、コントローラ１００の認証情報保持部１０４が保持するものと同様のため説明は省略する。
　（通信部３０５）
　通信部３０５は、コントローラ１００と通信を行うための通信インターフェイスである。サーバ３００とコントローラ１００との通信は、例えば、ＳＳＬ通信により行われる。ＳＳＬ通信に必要な証明書は、通信部３０５で保持する。
　＜１－３．動作＞
　以下、認証システム１０で行う、“機器登録処理”、“セッション更新処理”、“ＰＫＩに基づく相互認証～共有鍵の作成”、“共有鍵を用いた相互認証～セッションに係る情報の作成”、“機器履歴情報送信処理”、“制御情報送信処理”、“機器履歴情報ＭＡＣ（Ｍｅｓｓａｇｅ　Ａｕｔｈｅｎｔｉｃａｔｉｏｎ　Ｃｏｄｅ）送信処理”、“制御情報ＭＡＣ送信処理”について順に説明する。なお、“ＰＫＩに基づく相互認証～共有鍵の作成”は、“機器登録処理”において、“共有鍵を用いた相互認証～セッションに係る情報の作成”は、“機器登録処理”及び“セッション更新処理”において実行する処理であるが、便宜的にサブルーチン化して記載している。
　（機器登録処理）
　図１０及び図１１は、機器とコントローラとのそれぞれにおける機器登録処理の手順の一例を示したフローチャート図であり、図１２は、機器とコントローラとのやりとりを含む、機器登録処理の手順の一例を示したシーケンス図である。
　機器登録処理は、コントローラ１００と機器とが接続する際に行う処理であり、機器がコントローラ１００に接続要求をし、相互認証を行ってから互いを登録する手順である。まず、図１０及び図１１のフローチャートに沿って、機器及びコントローラのそれぞれにおける処理の概要を説明してから、図１２のシーケンス図に沿って、機器とコントローラとのやりとりを含む、機器登録処理のより詳細な手順について説明する。
　図１０のフローチャートに沿って、機器における機器登録処理の概要について説明する。
　まず、機器はコントローラに対して、接続要求とともに、機器自身の機器ＩＤ及び公開鍵証明書を送信する（ステップＳ１０１０）。
　次に、機器は、“ＰＫＩに基づく相互認証～共有鍵の作成”のサブルーチンを実行することで、コントローラとの相互認証を行った後、共有鍵を共有する（ステップＳ１０２０）。当該サブルーチン処理の詳細は後述する。
　ステップＳ１０２０のサブルーチンの戻り値が「正常」である場合（ステップＳ１０３０のＹＥＳ）、機器は“共有鍵を用いた相互認証～セッションに係る情報の作成”のサブルーチンを実行することにより、コントローラと共有鍵を用いた相互認証を行った後、セッションに係る情報である、グループ鍵及びセッション鍵の作成、セッション有効期間の設定を行う（ステップＳ１０４０）。当該、サブルーチン処理の詳細は後述する。
　ステップＳ１０４０のサブルーチンの戻り値が「正常」である場合（ステップＳ１０５０のＹＥＳ）、機器は、正当な接続相手としてコントローラの情報を登録する（ステップＳ１０６０）。
　一方、ステップＳ１０２０のサブルーチンの戻り値が「エラー」である場合（ステップＳ１０３０のＮＯ）、あるいは、ステップＳ１０４０のサブルーチンの戻り値が「エラー」である場合（ステップＳ１０５０のＮＯ）、機器は、機器登録処理を終了する。
　次に、図１１のフローチャートに沿って、コントローラにおける機器登録処理の概要について説明する。
　コントローラは、機器の接続要求、機器ＩＤ及び公開鍵証明書を待ち受ける（ステップＳ１１１０）。これらを受信しない場合（ステップＳ１１１０のＮＯ）、コントローラは、機器からの接続要求を待ち続ける。
　接続要求を受信した場合（ステップＳ１１１０のＹＥＳ）、コントローラは“ＰＫＩに基づく相互認証～共有鍵の作成”のサブルーチンを実行することで、機器との相互認証を行った後、共有鍵を共有する（ステップＳ１１２０）。当該サブルーチン処理の詳細は後述する。
　ステップＳ１１２０のサブルーチンの戻り値が「正常」である場合（ステップＳ１１３０のＹＥＳ）、コントローラは、“共有鍵を用いた相互認証～セッションに係る情報の作成”のサブルーチンを実行することで、機器と共有鍵を用いた相互認証を行った後、セッションに係る情報である、グループ鍵及びセッション鍵の作成、セッション有効期間の設定を行う（ステップＳ１１４０）。また、コントローラは、当該機器を基準機器として設定するか否かを判断する（ステップＳ１１４０）。当該サブルーチン処理の詳細は後述する。
　ステップＳ１１４０のサブルーチンの戻り値が「正常」である場合（ステップＳ１１５０のＹＥＳ）、コントローラは、コントローラと機器の情報をサーバ３００に送信する（ステップＳ１１６０）。
　そして、コントローラは、正当な接続相手として機器の情報を登録する（ステップＳ１１７０）。
　一方、ステップＳ１１２０のサブルーチンの戻り値が「エラー」である場合（ステップＳ１１３０のＮＯ）、あるいは、ステップＳ１１４０のサブルーチンの戻り値が「エラー」である場合（ステップＳ１１５０のＮＯ）、コントローラは機器登録処理を終了する。
　ここからは、図１２のシーケンス図に沿って、より詳細な処理の内容を機器とコントローラとのやりとりを含めて説明する。機器については、機器２００ａの例示で説明するが、機器２００ｂ及び機器２００ｃに関する処理も機器２００ａと同様の手順であることは言うまでもない。また、シーケンス図としては、エラーが発生しない場合の例を示しているが、エラー発生時の処理については、文章にて補足を行っている。
　機器登録処理は、コントローラ１００に新たな機器が接続する際に行う処理である。例えば、コントローラの属するホームエリアネットワークに新たな機器が追加されるタイミングや、当該ネットワークに電源ＯＦＦの状態で存在する機器の電源がＯＮになったタイミングなどに実行する。
　機器２００ａの機器管理部２０１は、通信部２０６を介し、コントローラ１００に対する接続要求を送信する（ステップＳ１０１）。このとき、機器２００ａの機器ＩＤ及び公開鍵証明書も合わせて送信する。
　コントローラ１００の機器管理部１０１は、通信部１０５を介して、接続要求を受け付け、認証処理部１０３にＰＫＩに基づく相互認証を実行させる。これを受け、コントローラ１００の認証処理部１０３と機器２００ａの認証処理部２０４とは、ＰＫＩに基づく相互認証処理を行い、互いの正当性を確認する（ステップＳ１０２）。
　そして、コントローラ１００の認証処理部１０３と機器２００ａの認証処理部２０４とは、鍵交換方式により、共有鍵を作成する（ステップＳ１０２）。当該共有鍵は、以降において行う相互認証において使用する。上記ステップＳ１０２の、“ＰＫＩに基づく相互認証～共有鍵の作成”は便宜的にサブルーチン化しており、手順は後述する。なお、当該サブルーチン処理からの戻り値が「エラー」である場合、コントローラと機器とは、機器登録処理を終了する。
　続いて、コントローラ１００の認証処理部１０３と機器２００ａの認証処理部２０４とは、作成した共有鍵を用いて相互認証を行うとともに、セッションに係る情報の作成を行う（ステップＳ１０３）。ステップＳ１０３において、改めて共有鍵を用いた相互認証を行うのは、共有鍵自体を検証するためでもある。ステップＳ１０２における共有鍵の作成は鍵交換方式により行っている。したがって、コントローラ１００と機器２００ａとのそれぞれにおいて、所定の手順により共有鍵を作成するため、それぞれで作成した共有鍵が同一であることを確認するためにも、ステップＳ１０３において、共有鍵を用いた相互認証を行うことが有用である。
　共有鍵を用いた相互認証が成功した場合、セッションに係る情報である、グループ鍵、セッション鍵、セッション有効期間の作成を行う（ステップＳ１０３）。また、機器２００ａを基準機器として設定するか否かを判断する（ステップＳ１０３）。ステップＳ１０３の、“共有鍵を用いた相互認証～セッションに係る情報作成”は便宜的にサブルーチン化しており、手順は後述する。なお、当該サブルーチン処理からの戻り値が「エラー」である場合、コントローラと機器とは機器登録処理を終了する。
　機器２００ａの認証処理部２０４は、機器管理部２０１を介して、コントローラ１００のコントローラＩＤ及び、当該コントローラ１００と共有する、共有鍵、グループ鍵、セッション鍵の情報を、機器情報保持部２０３の有する接続コントローラ管理テーブル１１００に登録する。また、セッション有効期間を、接続コントローラ管理テーブル１１００のセッション残り時間の項目に登録する（ステップＳ１０４）。
　コントローラ１００の機器管理部１０１は、コントローラ１００に係るコントローラＩＤ及び公開鍵証明書の証明書ＩＤ、並びに、機器２００ａに係る機器ＩＤ及び公開鍵証明書の証明書ＩＤをサーバ３００に送信する（ステップＳ１０５）。このとき、サーバとはＳＳＬ（Ｓｅｃｕｒｅ　Ｓｏｃｋｅｔ　Ｌａｙｅｒ）通信を行う。
　また、コントローラ１００の機器管理部１０１は、機器２００ａの機器ＩＤ及び、機器２００ａと共有する共有鍵、グループ鍵、セッション鍵の情報を、機器情報保持部１０２の有する接続機器管理テーブル１０００に登録する。このとき、セッション有効期間を、接続機器管理テーブル１０００のセッション残り時間の項目に登録する。また、機器２００ａを基準機器として設定する場合、接続機器管理テーブル１０００の基準機器の項目に、基準機器であることを登録する（ステップＳ１０６）。ステップＳ１０３の“共有鍵を用いた相互認証～セッションに係る情報作成”において、基準機器として設定するか否かの判断が行われており、例えば、コントローラに最初に接続した機器が、基準機器として設定される。
　サーバ３００は、通信部３０５を介して、コントローラ１００からコントローラ及び機器の情報を受信する。そして、機器情報管理部３０１は、当該コントローラのコントローラＩＤ及び証明書ＩＤ、並びに、認証された機器の機器ＩＤ及び証明書ＩＤを、機器情報保持部３０２が有する機器情報管理テーブル１３００に登録する（ステップＳ１０７）。
　（セッション更新処理）
　図１３及び図１４は、機器とコントローラとのそれぞれにおけるセッション更新処理の手順の一例を示したフローチャート図であり、図１５は、機器とコントローラとのやりとりを含む、セッション更新処理の手順の一例を示したシーケンス図である。
　セッション更新処理において、機器とコントローラ１００とは、改めて相互認証を行った上で、グループ鍵、セッション鍵、セッション残り時間の更新を行う。図１３及び図１４のフローチャートに沿って、機器及びコントローラのそれぞれにおける処理の概要を説明した後、図１５のシーケンス図に沿って、機器とコントローラとのやりとりを含む処理の詳細について説明する。
　まず、図１３のフローチャートに沿って、機器におけるセッション更新処理の概要について説明する。機器は、基準機器であるか、基準機器以外の機器であるかを問わず、次の手順で処理を行う。
　機器はセッション更新の開始を判定するために、セッション残り時間を監視する。または、コントローラからのセッション更新通知を待ち受ける（ステップＳ１２１０）。セッション残り時間が予め定めた所定値より大きい、かつ、コントローラからのセッション更新通知も受信しない場合（ステップＳ１２１０のＮＯ）、監視を続ける。
　セッション残り時間が予め定めた所定値以下となるか、あるいは、コントローラからセッション更新通知を受信した場合（ステップＳ１２１０のＹＥＳ）、機器はセッション更新を行うために、コントローラに対して、セッション更新要求を送信する（ステップＳ１２２０）。
　そして、“共有鍵を用いた相互認証～セッションに係る情報の作成”のサブルーチンを実行することで、コントローラと共有鍵を用いた相互認証を行った後、セッションに係る情報である、グループ鍵及びセッション鍵の作成、セッション有効期間の設定を行う（ステップＳ１２３０）。当該、サブルーチン処理の詳細は後述する。
　ステップＳ１２３０のサブルーチンの戻り値が「正常」である場合（ステップＳ１２４０のＹＥＳ）、機器は、ステップＳ１２３０にて作成した新たなセッションに係る情報を、セッション更新情報として登録する（ステップＳ１２５０）。
　一方、ステップＳ１２３０のサブルーチンの戻り値が「エラー」である場合（ステップＳ１２４０のＮＯ）、セッションの更新を行わずに、機器はセッション更新処理を終了する。
　次に、図１４のフローチャートに沿って、コントローラにおけるセッション更新処理の概要について説明する。
　コントローラは、機器からのセッション更新要求を待ち受ける（ステップＳ１３１０）。受信しなければ（ステップＳ１３１０のＮＯ）、機器からのセッション更新要求を待ち続ける。
　機器からセッション更新要求を受信すると（ステップＳ１３１０のＹＥＳ）、“共有鍵を用いた相互認証～セッションに係る情報の作成”のサブルーチンを実行することで、機器と共有鍵を用いた相互認証を行った後、セッションに係る情報である、グループ鍵及びセッション鍵の作成、セッション有効期間の設定を行う（ステップＳ１３２０）。当該、サブルーチン処理の詳細は後述する。
　ステップＳ１３２０のサブルーチンの戻り値が「正常」である場合（ステップＳ１３３０のＹＥＳ）、コントローラは、ステップＳ１３２０にて作成した新たなセッションに係る情報を、セッション更新情報として登録する（ステップＳ１３４０）。このとき、機器が基準機器である場合は、コントローラに接続するその他の各機器がセッション未更新であることを示す情報を登録する。また、機器が基準機器でない場合は、当該機器がセッション更新済であることを示す情報を登録する。すなわち、基準機器がセッション更新を行って以降、その他の各機器がセッションを更新済であるか、未更新であるかを、機器毎に管理する。
　一方、ステップＳ１３２０のサブルーチンの戻り値が「エラー」である場合（ステップＳ１３３０のＮＯ）、当該機器については、セッション更新情報の登録を行わないことで、セッションを更新しない。
　当該機器とのセッション更新を行ったか行っていないかに関わらず、他にセッションを更新していない機器が存在する場合（ステップＳ１３５０のＹＥＳ）、当該セッション未更新機器に対して、セッション更新通知を送信する（ステップＳ１３６０）。このとき、セッションが未更新である機器全てに対して、一斉にセッション更新通知を行ってもよいし、そのうちの一部、あるいは１つの機器に対して送ってもよいが、最終的には全ての未更新機器に対して、セッション更新通知を行い、セッションを更新することで全ての機器とのセッションを更新する。勿論、ステップＳ１３２０において、エラーが発生した機器は除く。
　全ての機器について、セッション更新処理が完了した場合（ステップＳ１３５０のＮＯ）、セッション更新処理を終了する。
　ここからは、図１５のシーケンス図に沿って、より詳細な処理を機器とコントローラとのやりとりを含めて説明する。機器については、一例として、機器２００ａが基準機器であり、機器２００ｂが基準機器以外の機器であるとする。また、シーケンス図については、エラーが発生しない場合の例を示しているが、エラー発生時の処理については、文章にて補足している。
　機器２００ａの機器管理部２０１は、接続コントローラ管理テーブル１１００が保持するセッション残り時間１１６０を監視し、予め定めた所定の閾値以下であるかを確認する。セッション残り時間が所定値より大きい場合、セッション残り時間の監視を続ける（ステップＳ１４１）。なお、機器２００ｂの機器管理部２０１も、機器２００ａと同様に、セッション残り時間の監視を行うが、機器２００ａよりも長いセッション残り時間を有するものとする。仮に、基準機器以外の機器が、基準機器よりも短いセッション残り時間を有することで、先にセッション更新処理を行っても問題ない。このとき、グループ鍵については、後述する“共有鍵を用いた相互認証～セッションに係る情報作成”のサブルーチンにおいて、基準機器が使用しているグループ鍵を取得することとなる。すなわち、現在使用しているグループ鍵と同じグループ鍵を取得することとなり、グループ鍵については更新が行われない。しかし、基準機器がセッション更新処理を行った時点で、基準機器以外の機器のセッション更新状態がクリアされることにより、当該機器はセッション未更新機器であると判定され、コントローラからセッション更新通知を受信する。この通知を受けて、当該機器がセッション更新を行うことで、基準機器がグループ鍵を更新するタイミングに合わせて、当該機器もグループ鍵の更新を行うこととなる。
　セッション残り時間が所定の閾値以下になった時点で、機器２００ａの機器管理部２０１は、認証処理部２０４にセッション更新を実行させる。認証処理部２０４は、まず、通信部２０６を介して、セッション更新要求をコントローラ１００に送信する（ステップＳ１４２）。
　コントローラ１００の機器管理部１０１は、通信部１０５を介して、セッション更新要求を受け付け、認証処理部１０３に、相互認証処理を実行させる。これを受け、コントローラ１００の認証処理部１０３と機器２００ａの認証処理部２０４とは、共有鍵を用いたチャレンジレスポンス認証による相互認証により、互いの正当性を確認する（ステップＳ１４３）。また、相互認証により互いの正当性が確認できた場合には、セッションに係る情報である、グループ鍵、セッション鍵、セッション有効期間の作成を行う（ステップＳ１４３）。
　ステップＳ１４３の、“共有鍵を用いた相互認証～セッションに係る情報作成”は、機器登録処理におけるステップＳ１０３と同様の処理であり、便宜的にサブルーチン化しており、手順は後述する。なお、当該サブルーチン処理からの戻り値が「エラー」である場合、コントローラと当該機器２００ａとはセッションを更新しない。すなわち、ステップＳ１４４及びステップＳ１４５のセッション更新情報の登録処理を行わずに、ステップＳ１４６へ進む。そして、後の“共有鍵を用いた相互認証～セッションに係る情報作成”のサブルーチンにおいて、機器２００ｂが基準機器として設定されることとなる。
　機器２００ａの機器管理部２０１は、ステップＳ１４３にて作成した、セッション鍵、グループ鍵、及びセッション有効期間を、機器情報保持部２０３の有する、接続コントローラ管理テーブル１１００に登録する（ステップＳ１４４）。このとき、セッション有効期間は、セッション残り時間の項目に登録する。
　また、コントローラ１００の機器管理部１０１は、ステップＳ１４３にて作成した、グループ鍵、セッション鍵、セッション有効期間を、機器情報保持部１０２の有する、接続機器管理テーブル１０００に登録する。セッション有効期間は、セッション残り時間１０６０の項目に登録する。このとき、機器２００ａに係るセッション更新状態１０７０は“更新済”に設定する。また、機器２００ａ以外の機器、すなわち、基準機器以外の機器に係るレコードに対しては、セッション更新状態１０７０の項目を“未更新”に更新する（ステップＳ１４５）。
　コントローラ１００の機器管理部１０１は、機器情報保持部１０２が保持する、接続機器管理テーブル１０００のセッション更新状態１０７０の項目を参照し、“未更新”の機器の有無を確認する。セッション更新状態１０７０の項目が“未更新”である機器が存在しない場合、全ての機器のセッション更新処理が行われたと判断し、処理を終了する。
　セッション更新状態１０７０が“未更新”である機器が存在する場合、コントローラ１００の機器管理部１０１は、当該機器に対して、セッション更新通知を行う（ステップＳ１４６）。図１５の例では、セッションが未更新である機器２００ｂに対するセッション更新通知を行う。なお、他にもセッション未更新の機器が存在する場合、当該機器に対してもセッション更新通知を行い、以降の処理を実施するものとする。このとき、セッションが未更新である機器全てに対して、一斉にセッション更新通知を行ってもよい。または、未更新機器のうちの１つの機器に対して送ってもよいし、いくつかの機器毎に送ってもよい。
　機器２００ｂの機器管理部２０１は、通信部２０６を介して、コントローラ１００が送信したセッション更新通知を受け付け、認証処理部２０４にセッション更新を実行させる。認証処理部２０４は、まず、通信部２０６を介して、コントローラ１００にセッション更新要求を送信する（ステップＳ１４７）。
　それから、基準機器以外の機器である機器２００ｂも、基準機器である機器２００ａに係るステップＳ１４３～Ｓ１４５と同様の手順でセッション更新を行う（ステップＳ１４８～ステップＳ１５０）。
　ただし、ステップＳ１４９において、コントローラ１００の機器管理部１０１は、ステップＳ１４８にて作成した、グループ鍵、セッション鍵、セッション有効期間を、機器情報保持部１０２の有する、接続機器管理テーブル１０００に登録するとともに、セッション更新状態１０７０の項目は“更新済”に更新する（ステップＳ１４９）。
　上記ステップＳ１４５において、全てのセッション未更新機器に対してセッション更新通知を送信することにより、コントローラは全ての機器とのセッション更新を行い、更新したグループ鍵を共有する。
　（ＰＫＩに基づく相互認証～共有鍵の作成）
　図１６及び図１７は、機器とコントローラとのそれぞれにおけるＰＫＩに基づく相互認証～共有鍵の作成の手順処理の手順の一例を示したフローチャート図であり、図１８は、機器とコントローラとのやりとりを含む、同処理の手順の一例を示したシーケンス図である。図１６及び図１７のフローチャートに沿って、機器及びコントローラのそれぞれにおける処理の概要を説明した後、図１８のシーケンス図に沿って、機器とコントローラとのやりとりを含む処理の詳細について説明する。
　まず、図１６のフローチャートに沿って、機器における処理の概要について説明する。
　機器は、コントローラから、コントローラＩＤ及び公開鍵証明書を待ち受ける。これらを受信せずに（ステップＳ１４１０のＮＯ）、エラーを受信した場合（ステップＳ１４２０のＹＥＳ）、当該サブルーチンの戻り値として、「エラー」をセットする（ステップＳ１４６０）。
　コントローラから、コントローラＩＤ及び公開鍵証明書、あるいは、エラーのいずれも受信しない場合（ステップＳ１４１０のＮＯ及びステップＳ１４２０のＮＯ）、コントローラからの情報を待ち続ける。
　コントローラＩＤ及び公開鍵証明書を受信した場合（ステップＳ１４１０のＹＥＳ）、コントローラから受信した公開鍵証明書について、証明書ＩＤがＣＲＬにないことを確認する（ステップＳ１４３０）。
　そして、証明書ＩＤがＣＲＬに記載されておらず失効していない場合（ステップＳ１４３０のＮＯ）、公開鍵証明書に付されている署名を検証する（ステップＳ１４４０）。
　ステップＳ１４４０において、コントローラの公開鍵証明書の署名の検証に成功した場合（ステップＳ１４４０のＹＥＳ）、機器はコントローラに検証成功を通知する（ステップＳ１４７０）。
　そして、機器はコントローラとの鍵交換により、共有鍵を共有する（ステップＳ１４８０）。当該鍵は、以降の相互認証に利用する。また、機器は、当該サブルーチンの戻り値として、「正常」をセットする（ステップＳ１４９０）。
　一方、公開鍵証明書の証明書ＩＤがＣＲＬ記載されていた場合（ステップＳ１４３０のＹＥＳ）、あるいは、署名検証に成功しなかった場合（ステップＳ１４４０のＮＯ）のいずれかである場合、コントローラの公開鍵証明書の検証が失敗したと判断して、機器は、コントローラに対して、エラー通知を送信する（ステップＳ１４５０）。そして、当該サブルーチンの戻り値としては、「エラー」をセットする（ステップＳ１４６０）。
　ステップＳ１４９０あるいはステップＳ１４６０にてセットされた戻り値を当該サブルーチンの処理結果として、呼び出し元の処理に返す（ステップＳ１５００）。
　次に、図１７のフローチャートに沿って、コントローラにおける処理の概要について説明する。
　まず、コントローラは、機器から受信した公開鍵証明書の証明書ＩＤがＣＲＬにないことを確認する（ステップＳ１６１０）。
　そして、証明書ＩＤがＣＲＬに記載されておらず失効していない場合（ステップＳ１６１０のＮＯ）、公開鍵証明書に付されている署名を検証する（ステップＳ１６２０）。
　公開鍵証明書の証明書ＩＤがＣＲＬ記載されていた場合（ステップＳ１６１０のＹＥＳ）、あるいは、署名御検証に成功しなかった場合（ステップＳ１６２０のＮＯ）のいずれかである場合、機器の公開鍵証明書の検証が失敗したとして、コントローラは機器に対してエラー通知を送信する（ステップＳ１６３０）。
　そして、当該サブルーチンの戻り値としては、「エラー」をセットする（ステップＳ１６７０）。
　ステップＳ１６２０にて、コントローラの公開鍵証明書の署名の検証に成功した場合（ステップＳ１６２０のＹＥＳ）、機器側の、コントローラの公開鍵証明書の検証結果を待ち受ける（ステップＳ１６５０）。
　機器から検証成功を受信せずに（ステップＳ１６５０のＮＯ）、エラー通知を受信した場合（ステップＳ１６６０のＹＥＳ）、当該サブルーチンの戻り値としては、「エラー」をセットする（ステップＳ１６７０）。
　機器から検証成功を受信せず（ステップＳ１６５０のＮＯ）、かつ、エラー受信もしない場合（ステップＳ１６６０のＮＯ）、機器からの検証結果を待ち続ける。
　機器から検証成功を受信した場合（ステップＳ１６５０のＹＥＳ）、コントローラと機器とは鍵交換により、共有鍵を共有する（ステップＳ１６８０）。当該鍵は、以降の相互認証に利用する。
　そして、コントローラは、当該サブルーチンの戻り値として、「正常」をセットする（ステップＳ１６９０）。
　ステップＳ１６９０あるいはステップＳ１６７０にてセットされた戻り値を当該サブルーチンの処理結果として、呼び出し元の処理に返す（ステップＳ１７００）。
　ここからは、図１８のシーケンス図に沿って、より詳細な処理を機器とコントローラとのやりとりを含めて説明する。機器については、機器２００ａの例示で説明するが、機器２００ｂ、機器２００ｃについても、同じ手順で処理が行われることはいうまでもない。また、シーケンス図については、エラーが発生しない場合の例を示しているが、エラー発生時の処理については、文章にて補足している。
　コントローラ１００の認証処理部１０３は、機器２００ａの公開鍵証明書の証明書ＩＤが、認証情報保持部１０４で保持するＣＲＬに記載されていないことを確認する（ステップＳ１１１）。
　ステップＳ１１１において、機器２００ａの証明書ＩＤがＣＲＬに記載されていない場合、コントローラ１００の認証処理部１０３は、機器２００ａの公開鍵証明書に付与されている認証局の電子署名が適切なものであるかを検証する（ステップＳ１１２）。このとき用いる電子署名方式及び検証方法は、ＥＣＤＳＡ（Ｅｌｌｉｐｔｉｃ　Ｃｕｒｖｅ　Ｄｉｇｉｔａｌ　Ｓｉｇｎａｔｕｒｅ　Ａｌｇｏｒｉｔｈｍ）に基づくものとする。ＥＣＤＳＡによる電子署名及び検証方法については、非特許文献１などに記載されている一般的な技術を用いるため説明は省略する。
　ステップＳ１１１において機器２００ａの証明書ＩＤがＣＲＬに記載されている場合、あるいは、ステップＳ１１２において電子署名の検証が成功しない場合、認証処理部１０３は、機器２００ａが正当な機器ではないと判断し、機器２００ａに対するエラー通知を行い、当該サブルーチンの呼び出し元である機器登録処理に対して、戻り値「エラー」を返す。このとき、エラー通知を受信した機器２００ａ側でも、戻り値「エラー」を返し、コントローラと機器との双方が当該サブルーチン処理を終了する。
　ステップＳ１１２において、電子署名の検証が成功した場合、コントローラ１００の認証処理部１０３は、機器２００ａが正当な機器であると判断し、通信部１０５を介して、コントローラ自身のコントローラＩＤ及び公開鍵証明書を機器２００ａに送信する（ステップＳ１１３）。
　機器２００ａの機器管理部２０１は、通信部２０６を介して、コントローラ１００のコントローラＩＤ及び公開鍵証明書を受け付け、認証処理部２０４にＰＫＩに基づく認証処理を実行させる。認証処理部２０４は、まず、コントローラの公開鍵証明書の証明書ＩＤが、認証情報保持部２０５で保持するＣＲＬに記載されていないことを確認する（ステップＳ１１４）。
　ステップＳ１１４において、コントローラ１００の証明書ＩＤがＣＲＬに記載されていない場合、機器２００ａの認証処理部２０４は、コントローラ１００の公開鍵証明書に付与されている認証局の電子署名が適切なものであるかを検証する（ステップＳ１１５）。このとき用いる電子署名方式及び検証方法は、ステップＳ１１２と同様に、ＥＣＤＳＡ（Ｅｌｌｉｐｔｉｃ　Ｃｕｒｖｅ　Ｄｉｇｉｔａｌ　Ｓｉｇｎａｔｕｒｅ　Ａｌｇｏｒｉｔｈｍ）に基づくものとし、説明は省略する。
　ステップＳ１１４においてコントローラの証明書ＩＤがＣＲＬに記載されている場合、あるいは、ステップＳ１１５において電子署名の検証が成功しない場合、認証処理部２０４は、コントローラ１００が正当な機器ではないと判断し、コントローラに対するエラー通知を行い、当該サブルーチンの呼び出し元である機器登録処理に対して、戻り値「エラー」を返す。このとき、エラー通知を受信したコントローラ側でも、戻り値「エラー」を返し、コントローラと機器との双方が当該サブルーチン処理を終了する。
　ステップＳ１１５において、電子署名の検証が成功した場合、機器２００ａの認証処理部２０４は、コントローラ１００が正当なコントローラであると判断し、コントローラ１００に対して検証成功を通知する（ステップＳ１１６）。
　次に、機器２００ａの認証処理部２０４とコントローラ１００の認証処理部１０３とは、共有鍵を共有するための処理として、鍵交換を行う（ステップＳ１１７、Ｓ１１８）。ここで、実施する鍵交換方式は、楕円曲線暗号を用いた鍵交換方式であるＥＣＤＨ（Ｅｌｌｉｐｔｉｃ　Ｃｕｒｖｅ　Ｄｉｆｆｉｅ－Ｈｅｌｌｍａｎ）とする。ＥＣＤＨについては、非特許文献２などに記載されている一般的な技術を用いるため詳細な説明は省略する。
　ＥＣＤＨによる鍵交換において、コントローラ１００の認証処理部１０３は、コントローラ自身の秘密鍵と機器２００ａの公開鍵証明書に含まれている機器２００ａの公開鍵とを用いて所定の手順により値を算出する。一方、機器２００ａの認証処理部２０４は、機器自身の秘密鍵とコントローラ１００の公開鍵証明書に含まれているコントローラ１００の公開鍵とを用いて、所定の手順により値を算出する。ここで、コントローラ１００と機器２００ａとのそれぞれにおいて算出された値は同じ結果となる。このようにして共有した値から共有鍵を算出する。本実施形態では、ＡＥＳ（Ａｄｖａｎｃｅｄ　Ｅｎｃｒｙｐｔｉｏｎ　Ｓｔａｎｄａｒｄ）の鍵長１２８ビットを共有鍵として用いることとし、上記で共有した値からハッシュ値を計算し、計算したハッシュ値の上位１２８ビットを共有鍵とする。
　（共有鍵を用いた相互認証～セッションに係る情報の作成）
　図１９及び図２０は、それぞれ機器とコントローラとのそれぞれにおける共有鍵を用いた相互認証～セッションに係る情報の作成処理の手順の一例を示したフローチャート図であり、図２１は、機器とコントローラとのやりとりを含む同処理の手順の一例を示したシーケンス図である。
　本実施形態においては、共有鍵を用いた相互認証として、乱数を使用したチャレンジレスポンス認証を行うこととする。
　図１９及び図２０のフローチャートに沿って、機器及びコントローラのそれぞれにおける処理の概要を説明した後、図２１のシーケンス図に沿って、機器とコントローラとのやりとりを含む処理の詳細について説明する。
　まず、図１９のフローチャートに沿って、機器における共有鍵を用いた相互認証～セッションに係る情報の作成処理の概要について説明する。
　機器は、コントローラから、コントローラが作成した乱数Ａの受信を待ち受け、受信しない場合（ステップＳ１８１０のＮＯ）は待ち続ける。
　コントローラから乱数Ａを受信した場合（ステップＳ１８１０のＹＥＳ）、機器は、受信した乱数Ａの暗号化を行うとともに、別の乱数である乱数Ｂの作成を行う（ステップＳ１８２０）。
　そして、機器は、暗号化した乱数Ａである暗号化乱数Ａ’及び乱数Ｂをコントローラに送信する（ステップＳ１８３０）。
　その後、機器は、コントローラ側での処理を待ち受ける。コントローラから、暗号化乱数Ｂ’、暗号化セッション鍵、暗号化グループ鍵、セッション有効期間を受信せずに（ステップＳ１８４０のＮＯ）、エラーを受信した場合（ステップＳ１８５０のＹＥＳ）、当該サブルーチンの戻り値として、「エラー」をセットする（ステップＳ１８８０）。
　コントローラから暗号化乱数Ｂ’、暗号化セッション鍵、暗号化グループ鍵、セッション有効期間を受信せずに（ステップＳ１８４０のＮＯ）、エラーも受信しない場合（ステップＳ１８５０のＮＯ）、コントローラからのいずれかの情報の受信を待ち続ける。
　機器は、コントローラらか、暗号化乱数Ｂ’、暗号化セッション鍵、暗号化グループ鍵、セッション有効期間を受信した場合（ステップＳ１８４０のＹＥＳ）、まず、乱数Ｂに関する検証を行う（ステップＳ１８６０）。機器は、保持している共有鍵で、受信した暗号化乱数Ｂ’を復号する。復号結果の値が、ステップＳ１８２０において機器自身が作成した乱数Ｂと合致する場合、乱数Ｂの検証が成功したと判断する。
　乱数Ｂの検証が成功しなかった場合（ステップＳ１８６０のＮＯ）、コントローラへエラー通知を行う（ステップＳ１８７０）。
　そして、当該サブルーチンの戻り値として、「エラー」をセットする（ステップＳ１８８０）。
　乱数Ｂの検証が成功した場合（ステップＳ１８６０のＹＥＳ）、コントローラから受信した、グループ鍵及びセッション鍵を復号する（ステップＳ１８９０）。
　そして、機器は、コントローラに対して、検証成功を通知する（ステップＳ１９００）。
　当該サブルーチンの戻り値としては、「正常」をセットする（ステップＳ１９１０）。
　ステップＳ１９１０あるいはステップＳ１８８０にてセットされた戻り値を当該サブルーチンの処理結果として、呼び出し元の処理に返す（ステップＳ１９２０）。
　次に、図２０のフローチャートに沿って、コントローラにおける共有鍵を用いた相互認証～セッションに係る情報の作成処理の概要について説明する。
　コントローラは乱数Ａを作成し、機器に送信する（ステップＳ２０１０）。
　そして、機器側での処理で作成される暗号化乱数Ａ’と乱数Ｂとを待ち受ける。機器から暗号化乱数Ａ’及び乱数Ｂを受信しない場合（ステップＳ２０２０のＮＯ）、受信するまで待ち続ける。
　暗号化乱数Ａ’、乱数Ｂを受信した場合（ステップＳ２０２０のＹＥＳ）、乱数Ａに関する検証を行う（ステップＳ２０３０）。機器は、保持している共有鍵で、受信した暗号化乱数Ａ’を復号する。復号結果の値が、ステップＳ２０１０においてコントローラ自身が作成した乱数Ａと合致する場合、乱数Ａの検証が成功したと判断する。
　乱数Ａの検証が成功しなかった場合（ステップＳ２０３０のＮＯ）、機器へエラー通知を行う（ステップＳ２０４０）。そして、当該サブルーチンの戻り値として、「エラー」をセットする（ステップＳ２１５０）。
　乱数Ａの検証が成功した場合（ステップＳ２０３０のＹＥＳ）、機器から受信した乱数Ｂを暗号化する（ステップＳ２０５０）。
　そして、機器が基準機器であるか否かを確認する（ステップＳ２０６０）。機器がコントローラに対して、最初に接続要求を行った機器である場合、基準機器である機器との接続が切断された場合などで、基準機器の設定がなされていない場合は、当該機器を基準機器とする。
　機器が基準機器である場合（ステップＳ２０６０のＹＥＳ）、グループ鍵を作成する（ステップＳ２０７０）。一方、機器が基準機器でない場合（ステップＳ２０６０のＮＯ）、既に作成して保持しているグループ鍵を当該機器とも共有するために、グループ鍵のデータを取得する（ステップＳ２０８０）。
　また、コントローラは、セッション鍵の作成とセッション有効期間の設定とを行う（ステップＳ２０９０）。
　そして、グループ鍵及びセッション鍵を共有鍵で暗号化する（ステップＳ２１００）。
　その後、ステップＳ２０５０～ステップＳ２１００の処理で取得した、暗号化乱数Ｂ’、暗号化セッション鍵、暗号化グループ鍵、セッション有効期間を、機器に送信する（ステップＳ２１１０）。
　機器側の検証結果を待ち受け、検証成功を受信しない場合（ステップＳ２１２０のＮＯ）、かつ、エラーを受信した場合（ステップＳ２１４０のＹＥＳ）、当該サブルーチンの戻り値として、「エラー」をセットする（ステップＳ２１５０）。
　機器側の検証結果を受信しない場合（ステップＳ２１２０のＮＯ）、かつ、エラーも受信しない場合（ステップＳ２１４０のＮＯ）、機器からの結果を待ち続ける。
　機器から検証成功を受信した場合（ステップＳ２１２０のＹＥＳ）、当該サブルーチンの戻り値としては、「正常」をセットする（ステップＳ２１３０）。
　ステップＳ２１３０あるいはステップＳ２１５０にてセットされた戻り値を当該サブルーチンの呼び出し元の処理に返す（ステップＳ２１６０）。
　ここからは、図２１のシーケンス図に沿って、より詳細な処理を機器とコントローラとのやりとりを含めて説明する。機器については、機器２００ａを用いて説明を行うが、機器２００ｂ及び機器２００ｃについても同様の手順にて処理を行うことは言うまでもない。また、シーケンス図については、エラーが発生しない場合の例を示しているが、エラー発生時の処理については、文章にて補足している。
　まず、コントローラ１００の認証処理部１０３は、任意の乱数Ａを作成し、機器２００ａへ送信する（ステップＳ１２１）。
　機器２００ａの認証処理部２０４は、通信部２０６を介して受信した乱数Ａを、保持している共有鍵を用いて暗号化し、暗号化乱数Ａ’を作成する（ステップＳ１２２）。また、認証処理部２０４は、任意の乱数Ｂを作成する（ステップＳ１２２）。
　機器２００ａの認証処理部２０４は、ステップＳ１２２において暗号化した暗号化乱数Ａ’と乱数Ｂとを、コントローラ１００に送信する（ステップＳ１２３）。
　コントローラ１００の認証処理部１０３は、暗号化乱数Ａ’と乱数Ｂとを受信する。認証処理部１０３は、暗号化乱数Ａ’を共有鍵で復号する。復号結果の値と、ステップＳ１２１においてコントローラ自身が作成した乱数Ａとが一致した場合、認証処理部１０３は、乱数Ａに関する検証が成功したと判断する（ステップＳ１２４）。
　ステップＳ１２４において、乱数Ａの検証が成功しない場合、コントローラの認証処理部１０３は、機器に対するエラー通知を行い、当該サブルーチンの呼び出し元に対して、戻り値「エラー」を返す。このとき、エラー通知を受信した機器側でも、戻り値「エラー」を返し、コントローラと機器との双方が当該サブルーチン処理を終了する。
　ステップＳ１２４において、乱数Ａの検証が成功した場合、コントローラの認証処理部１０３は、機器２００ａより受信した乱数Ｂを共有鍵で暗号化し、暗号化乱数Ｂ’を作成する（ステップＳ１２５）。
　続いて、コントローラの認証処理部１０３は、機器情報保持部１０２の接続機器管理テーブル１０００の基準機器１０８０の項目を参照し、機器２００ａが基準機器であるかを確認する。機器２００ａが基準機器である場合、グループ鍵を作成する（ステップＳ１２６）。グループ鍵はＡＥＳの鍵長１２８ビットとし、任意の一般的技術を用いて作成するため説明は省略する。また、機器２００ａがコントローラに対して、最初に接続要求を行った機器である場合や基準機器である機器との接続が切断された場合などで、基準機器の設定がなされていない場合は、当該機器２００ａを基準機器として設定し、グループ鍵の作成を行う。
　一方、接続機器管理テーブル１０００を参照し、機器２００ａが基準機器ではないことが確認された場合、認証処理部１０３は、機器情報保持部１０２の保持する接続機器管理テーブル１０００より、既に作成済のグループ鍵の情報を取得する。
　また、コントローラの認証処理部１０３は、セッション鍵を作成する（ステップＳ１２７）。セッション鍵についても、グループ鍵と同様、ＡＥＳの鍵長１２８ビットとし、任意の一般的技術を用いて作成する。
　続いて、コントローラの認証処理部１０３は、セッション有効期間を設定する（ステップＳ１２８）。このとき、認証処理部１０３は、予め定めた所定値（例えば、２４時間あるいは７２時間など）を、セッション有効期間とする。
　コントローラの認証処理部１０３は、ステップＳ１２６、Ｓ１２７で得られた、グループ鍵及びセッション鍵の情報を、共有鍵を用いて暗号化する（ステップＳ１２９）。
　認証処理部１０３は、ステップＳ１２５で暗号化した暗号化乱数Ｂ’、ステップＳ１２９で暗号化した暗号化グループ鍵、暗号化セッション鍵、及びステップＳ１２８で設定したセッション有効期間を、通信部１０５を介して、機器２００ａに送信する（ステップＳ１３０）。
　機器２００ａの認証処理部２０４は、コントローラ１００より受信した暗号化乱数Ｂ’を検証する（ステップＳ１３１）。認証処理部２０４は、保持している共有鍵で暗号化乱数Ｂ’を復号する。復号結果の値が、ステップＳ１２２において機器２００ａ自身が作成した乱数Ｂと合致する場合、認証処理部２０４は、乱数Ｂの検証が成功したと判断する。
　ステップＳ１３１において、乱数Ｂの検証が成功しない場合、認証処理部２０４は、コントローラ１００が正当なコントローラではないと判断し、コントローラ１００に対するエラー通知を行い、当該サブルーチンの呼び出し元に対して、戻り値「エラー」を返す。このとき、エラー通知を受信したコントローラ側でも、戻り値「エラー」を返し、コントローラと機器との双方が当該サブルーチン処理を終了する。
　ステップＳ１３１において、乱数Ｂの検証が成功した場合、機器２００ａの認証処理部２０４は、暗号化グループ鍵及び暗号化セッション鍵を共有鍵で復号する（ステップＳ１３２）。
　また、機器２００ａの認証処理部２０４は、コントローラ１００に対して検証成功を通知する（ステップＳ１３３）。
　（機器履歴情報送信処理）
　図２２は、機器２００ａからサーバ３００に対して、機器履歴情報を送信する手順の一例を示したシーケンス図である。このような機器履歴情報の送信は、定期的、あるいは不定期に行う。また、以下では機器２００ａの例示として手順の説明を行うが、機器２００ｂ、機器２００ｃについても処理の手順は同様である。
　機器の機器管理部２０１は、機器履歴保持部２０２に蓄積した機器履歴情報をセッション鍵で暗号化し、機器自身の機器ＩＤとともにコントローラ１００に送信する（ステップＳ１６１）。
　コントローラ１００の機器管理部１０１は、通信部１０５を介して、機器ＩＤ及び暗号化された機器履歴情報を受信する。そして、機器情報保持部１０２が有する接続機器管理テーブル１０００より、機器ＩＤに紐づくセッション鍵を取得し、受信した機器履歴情報を復号する（ステップＳ１６２）。
　コントローラ１００の通信部１０５とサーバ３００の通信部３０５とは、ＳＳＬ認証を行い、暗号通信路を確立する（ステップＳ１６３）。ここで、ＳＳＬ認証は一般的な技術を用いることから説明を省略する。
　コントローラ１００の機器管理部１０１は、通信部１０５を介して、コントローラ自身のコントローラＩＤ、機器から受信した機器ＩＤ、復号した機器履歴情報を、サーバ３００に送信する（ステップＳ１６４）。
　サーバ３００の機器情報管理部３０１は、通信部３０５を介して受信した、コントローラＩＤ、機器ＩＤ、機器履歴情報を、機器情報保持部３０２が有する機器情報管理テーブル１３００に登録する（ステップＳ１６５）。
　（制御情報送信処理）
　図２３は、サーバ３００が機器２００ａの制御を実行する手順の一例を示したシーケンス図である。サーバ３００は、コントローラ１００に対して、機器２００ａを制御するための制御依頼情報を送信する。制御依頼を受付けたコントローラ１００は、機器２００ａに対する制御コマンドを作成及び送信し、制御依頼に応じた機能を機器２００ａに実行させる。このようなサーバ３００から機器２００ａに対する制御依頼は、定期的、あるいは不定期に行われる。制御依頼には、例えば、機器に実行させる機能、ディスプレイに表示させる内容などが含まれる。
　以下では機器２００ａの例示として手順の説明を行うが、機器２００ｂ、機器２００ｃについても処理の手順は同様である。
　サーバ３００の通信部３０５とコントローラ１００の通信部１０５とは、ＳＳＬ認証を行い、暗号通信路を確立する（ステップＳ１７１）。
　サーバ３００の機器情報管理部３０１は、機器２００ａに所定の動作を実行させるための制御依頼情報を作成する。そして、通信部３０５を介して、コントローラ１００に送信する（ステップＳ１７２）。
　コントローラ１００の機器管理部１０１は、通信部１０５を介して、制御依頼情報を受信する。そして、機器管理部１０１は、当該制御依頼情報が、ネットワーク内のどの機器に対するどのような制御依頼であるかを確認し、当該制御依頼に応じて、機器２００ａに実行させるための制御コマンドを作成する（ステップＳ１７３）。
　そして、ステップＳ１７３で作成した制御コマンドが、複数の機器向けの指示である場合、コントローラ１００の機器管理部１０１は、グループ鍵を用いて、制御コマンドを暗号化する（ステップＳ１７４）。このとき、グループ鍵を用いて暗号化した旨を意味する情報を、送信する制御コマンドのヘッダ部分に付与してもよい。
　ステップＳ１７３で作成した制御コマンドが、単一の機器向けの指示である場合、コントローラ１００の機器管理部１０１は、セッション鍵を用いて、制御コマンドを暗号化する（ステップＳ１７５）。このとき、セッション鍵を用いて暗号化した旨を意味する情報を、送信する制御コマンドのヘッダ部分に付与してもよい。
　コントローラ１００の通信部１０５は、グループ鍵あるいはセッション鍵を用いて暗号化した制御コマンドを、対象の機器に送信する（ステップＳ１７６）。
　機器２００ａは、通信部１０５を介して、暗号化された制御コマンドを受信し、グループ鍵またはセッション鍵で復号化する（ステップＳ１７７）。このとき、グループ鍵あるいはセッション鍵のどちらを用いて復号するかの判断は、ステップＳ１７４またはステップＳ１７５において、ヘッダ部分に付与した情報を用いて判断してもよい。または、グループ鍵とセッション鍵とのそれぞれを用いて、制御コマンドを復号し、復号結果を用いて判断するとしてもよい。
　（機器履歴情報ＭＡＣ送信処理）
　機器からコントローラに機器履歴情報を送信する場合において、本来機器履歴情報の送信が認められていない第三者による、送信元機器への成りすまし送信が問題となることがある。
　ここで説明する機器履歴情報ＭＡＣ送信処理は、上記成りすまし送信に対抗するために、送信元機器が、機器履歴情報の暗号化に加えて、ヘッダ、送信元アドレス、送信先アドレスを含めたＭＡＣを生成し、暗号化された機器履歴情報と共に生成したＭＡＣを送信する。
　このため、例えば、第三者が、ヘッダ、送信元アドレス、送信先アドレス等を書き換える改ざんによる成りすまし送信を行ったとしても、ヘッダ、送信元アドレス、送信先アドレス、機器履歴情報を含むＭＡＣについてのＭＡＣ検証を行うことでその改ざんを検出することができる。
　以下、機器履歴情報ＭＡＣ送信処理について、図２４、図２５を参照しながら、機器２００ａが、ホームエリアネットワーク４００に接続する他の全ての機器（ここでは、機器２００ｂとしている。）及びコントローラ１００に対して、機器履歴情報をマルチキャスト送信する場合を例に挙げて説明する。
　図２４は、暗号化前と暗号化後のメッセージフォーマットのデータ構成図である。
　図２４（ａ）は、暗号化前の機器履歴情報（以下、この暗号化前の機器履歴情報と、後述する制御情報ＭＡＣ送信処理における暗号化前の制御情報とのことを、便宜上「送信データ」とも呼ぶ。）を含む、暗号化前のメッセージフォーマットのデータ構造図である。
　同図に示される通り、暗号化前のメッセージフォーマットは、ヘッダ２４０１と、送信元アドレス２４０２と、送信先アドレス２４０３と、送信データ２４０４とから構成される。
　ヘッダ２４０１は、送信データが複数のパケットに分割される場合に付与されるフラグメントのフラグ、フラグメントの番号等を含む。
　送信元アドレス２４０２は、送信データ２４０４を送信する機器のアドレス、例えば、ＩＰ（Internet Protocol）アドレス、ＭＡＣ（Media Access Control）アドレス等であり、送信する機器を識別する情報を含む。
　送信先アドレス２４０３は、送信データ２４０４を受信する機器又はコントローラのアドレス、例えば、ＩＰアドレス、ＭＡＣアドレス等であり、受信する機器又はコントローラを識別する情報を含む。マルチキャスト送信におけるマルチキャストアドレスを含むとしてもよい。
　機器２００は、送信データ２４０４を平文として暗号化する。また、ヘッダ２４０１と、送信元アドレス２４０２と、送信先アドレス２４０３と、送信データ２４０４とを平文としてＭＡＣを生成する。このとき、暗号化は、ＡＥＳで暗号化し、ＭＡＣの生成は、ＡＥＳのＣＢＣ－ＭＡＣ（Cipher Block Chaining MAC）、ＨＭＡＣ（Hash-based MAC）で生成するとしてもよい。また、暗号化と認証用データの作成を、ＡＥＳ－ＣＣＭ（Counter with CBC MAC）やＡＥＳ－ＧＣＭ（Galois/Counter Mode）等の認証付暗号化で行うとしてもよい。認証付暗号化を行う場合でも、暗号化は、送信データ２４０４を平文とし、ＭＡＣ生成は、ヘッダ２４０１と、送信元アドレス２４０２と、送信先アドレス２４０３と、送信データ２４０４とを平文として実施する。
　図２４（ｂ）は、暗号化後のメッセージフォーマットのデータ構造図である。
　同図に示される通り、暗号化後のメッセージフォーマットは、ヘッダ２４０１と、送信元アドレス２４０２と、送信先アドレス２４０３と、認証付暗号化データ２４０５とから構成される。
　認証付暗号化データ２４０５は、暗号化した送信データとＭＡＣとを結合したデータである。
　図２５は、機器履歴情報ＭＡＣ送信処理手順の一例として、機器２００ａから、ホームエリアネットワーク４００に接続する他の全ての機器及びコントローラ（ここでは、機器２００ｂ、コントローラ１００であるとしている。）に対して、機器履歴情報をマルチキャスト送信する場合の手順を示したシーケンス図である。
　このような機器履歴情報の送信は、定期的、あるいは不定期に行う。
　機器２００ａは、機器履歴保持部２０２に蓄積した機器履歴情報をグループ鍵で暗号化する。このとき、グループ鍵で暗号化した旨の情報を、送信する履歴情報のヘッダ部分に付与するとしてもよい。
　そして、機器２００ａは、ヘッダと、送信元アドレスと、送信先アドレスと、履歴情報とからＭＡＣを生成する（ステップＳ２５０１）。
　ＭＡＣを生成すると、機器２００ａは、一斉同報通信を利用して、機器２００ｂと、コントローラ１００とに対して、図２４（ｂ）に示された暗号化後のメッセージフォーマットの形式で、認証付暗号化データを送信する（ステップＳ２５０２）。また、この際、機器２００ａは、自身の機器ＩＤも併せて送信する。
　コントローラ１００は、機器２００ａから受信した暗号化した送信データをグループ鍵で復号して機器履歴情報を取得し、ヘッダと、送信元アドレスと、送信先アドレスと、送信データとを用いてＭＡＣ検証を行う（ステップＳ２５０３）。このとき、ヘッダに、グループ鍵で暗号化した旨の情報が付与されている場合には、その情報を参照して、グループ鍵で復号することを決定するとしてもよい。
　ステップＳ２５０４の処理において、ＭＡＣ検証に成功した場合に（ステップＳ２５０４：Ｙｅｓ）、コントローラ１００は、サーバ３００との間でＳＳＬ認証を行い、暗号通信路を確立する（ステップＳ２５０５）。
　コントローラ１００は、自身のコントローラＩＤ、機器２００ａから受信した機器ＩＤ、復号した機器履歴情報を、サーバ３００に送信する（ステップＳ２５０６）。
　サーバ３００は、コントローラ１００から受信したコントローラＩＤ、機器ＩＤ、機器履歴情報を、機器情報保持部３０２が有する機器情報管理テーブル１３００に登録する（ステップＳ２５０７）。
　ステップＳ２５０４の処理において、ＭＡＣ検証に成功しなかった場合に（ステップＳ２５０４：Ｎｏ）、コントローラ１００は、サーバ３００への機器履歴情報の送信を行わない。また、ＭＡＣ検証に成功しなかった場合に、ホームエリアネットワーク４００に接続する他の全ての機器及びコントローラに対して、ＭＡＣ検証に成功しなかった旨の通知を行ってもよい。
　機器２００ｂは、機器２００ａから受信した暗号化した送信データをグループ鍵で復号して機器履歴情報を取得し、ヘッダと、送信元アドレスと、送信先アドレスと、送信データとを用いてＭＡＣ検証を行う（ステップＳ２５０８）。このとき、ヘッダに、グループ鍵で暗号化した旨の情報が付与されている場合には、その情報を参照して、グループ鍵で復号することを決定するとしてもよい。
　ステップＳ２５０９の処理において、ＭＡＣ検証に成功した場合に（ステップＳ２５０９：Ｙｅｓ）、機器２００ｂは、機器履歴情報を利用した処理を行うことができる（ステップＳ２５１０）。
　ステップＳ２５０９の処理において、ＭＡＣ検証に成功しなかった場合に（ステップＳ２５０９：Ｙｅｓ）、機器２００ｂは、機器履歴情報を利用した処理を行わない。また、ＭＡＣ検証に成功しなかった場合に、ホームエリアネットワーク４００に接続する他の全ての機器２００及びコントローラ１００に対して、ＭＡＣ検証に成功しなかった旨の通知を行ってもよい。
　ここでは、機器履歴情報ＭＡＣ送信処理について、機器２００ａが、機器履歴情報を、ホームエリアネットワーク４００に接続する他の全ての機器２００及びコントローラ１００に対してマルチキャスト送信する場合を例に挙げて説明した。
　これに対して、ステップＳ２５０２の処理において、機器２００ａが、機器履歴情報を、コントローラ１００にのみ送信し、ホームエリアネットワーク４００に接続する他の機器には送信しない場合の例も考えられる。
　この場合には、ステップＳ２５０８～ステップＳ２５１０の処理が発生することはない。また、この場合には、ステップＳ２５０１の処理において、機器２００ａは、機器履歴情報の暗号化を、セッション鍵で暗号化し、ステップＳ２５０３の処理において、コントローラ１００は、機器履歴情報の復号化を、セッション鍵で復号化するとしてもよい。
　（制御情報ＭＡＣ送信処理）
　コントローラから機器に制御コマンドを送信する場合において、本来制御コマンドの送信が認められていない第三者による、送信元コントローラへの成りすまし送信が問題となることがある。
　ここで説明する制御情報ＭＡＣ送信処理は、上記成りすまし送信に対抗するために、送信元コントローラが、制御コマンドの暗号化に加えて、ヘッダ、送信元アドレス、送信先アドレス、制御コマンドを含めたＭＡＣを生成し、暗号化された制御コマンドと共に生成したＭＡＣを送信する。
　このため、例えば、第三者が、ヘッダ、送信元アドレス、送信先アドレス等を書き換える改ざんによる成りすまし送信を行ったとしても、ヘッダ、送信元アドレス、送信先アドレスを含むＭＡＣについてのＭＡＣ検証を行うことでその改ざんを検出することができる。
　以下、制御情報送信処理（図２３等参照）から、その一部の処理が変更された制御情報ＭＡＣ送信処理について、図２４、２６を参照しながら説明する。
　図２４（ａ）は、前述した通り、暗号化前のメッセージフォーマットのデータ構造図である。
　機器履歴情報ＭＡＣ送信処理において、送信データ２４０４が、暗号化前の機器履歴情報である場合について説明したが、この制御情報ＭＡＣ送信処理においては、送信データ２４０４が、暗号化前の制御コマンドである場合の例となっている。
　図２４（ｂ）は、前述した通り、暗号化後のメッセージフォーマットのデータ構成図である。
　機器履歴情報ＭＡＣ送信処理において、認証付暗号化データ２４０５が、暗号化した履歴情報とＭＡＣとを結合したデータである場合について説明したが、この制御情報ＭＡＣ処理においては、認証付暗号化データ２４０５が、暗号化した制御コマンドとＭＡＣとを結合したデータである場合の例となっている。
　図２６は、制御情報ＭＡＣ送信処理手順の一例を示すシーケンス図である。
　この制御情報ＭＡＣ送信処理は、前述した制御情報送信処理からその処理の一部が変更されたものとなっている。
　このような制御情報ＭＡＣ送信処理は、定期的、あるいは不定期に行う。
　ステップＳ２６０１～ステップＳ２６０３の処理は、制御情報送信処理におけるステップＳ１７１～ステップＳ１７３の処理と同様の処理である。このため、これらの処理の説明は、既に説明済であるため、省略する。
　ステップＳ２６０３の処理が終了すると、ステップＳ２６０３の処理において生成した制御コマンドが複数の機器向けの指示である場合、コントローラ１００は、生成した制御コマンドをグループ鍵で暗号化する。このとき、グループ鍵で暗号化した旨の情報を、送信する制御コマンドのヘッダ部分に付与するとしてもよい。
　そして、コントローラ１００は、ヘッダと、送信元アドレスと、送信先アドレスと、制御コマンドとからＭＡＣを生成する（ステップＳ２６０４）。
　ステップＳ２６０３の処理において生成した制御コマンドが単一の機器向けの指示である場合、コントローラ１００は、生成した制御コマンドをセッション鍵で暗号化する。このとき、グループ鍵で暗号化した旨の情報を、送信する制御コマンドのヘッダ部分に付与するとしてもよい。
　そして、コントローラ１００は、ヘッダと、送信元アドレスと、送信先アドレスと、制御コマンドとからＭＡＣを生成する（ステップＳ２６０５）。
　ＭＡＣを生成すると、コントローラは、対象となる機器に対して、図２４（ｂ）に示された暗号化後のメッセージフォーマットの形式で、認証付暗号化データを送信する（ステップＳ２６０６）。
　認証付暗号化データを受信した機器（ここでは、認証付暗号化データを受信した機器の代表として、例えば、機器２００ａを用いて説明する。）は、コントローラ１００から受信した暗号化した送信データを、グループ鍵又はセッション鍵で復号して制御コマンドを取得し、ヘッダと、送信元アドレスと、送信先アドレスと、送信データとを用いてＭＡＣ検証を行う（ステップＳ２６０７）。このとき、ヘッダに、グループ鍵で暗号化した旨の情報又はセッション鍵で暗号化した旨の情報が付与されている場合には、その情報を参照して、グループ鍵とセッション鍵とのいずれを用いて復号するかを決定するとしてもよい。
　ステップＳ２６０８の処理において、ＭＡＣ処理に成功した場合に（ステップＳ２６０８：Ｙｅｓ）、機器２００ａは、復号された制御コマンドの指示に従って動作を行う（ステップＳ２６０９）。
　ステップＳ２６０８の処理において、ＭＡＣ処理に成功しなかった場合に（ステップＳ２６０８：Ｎｏ）、機器２００ａは、復号された制御コマンドの指示に従わない。また、ＭＡＣ検証に成功しなかった場合に、ホームエリアネットワーク４００に接続する他の全ての機器２００及びコントローラ１００に対して、ＭＡＣ検証に成功しなかった旨の通知を行ってもよい。
　ここでは、ＭＡＣ対象（図２４（ａ）参照）が、ヘッダ２４０１、送信元アドレス２４０２、送信先アドレス２４０３、送信データ２４０４からなるとして説明した。なお、セッション鍵を利用して送信データを暗号化する場合には、ＭＡＣ対象が送信データ２４０４からのみなるとしてもよい。この場合には、送信データ２４０４に、カウンターやシーケンス番号等が含まれる。セッション鍵は、コントローラ１００と該当する機器２００とのみが共有するため、第三者による成りすましや再送攻撃は難しい。
　本開示の一態様では、制御コマンドの送信において次のようにしてもよい。
　コントローラ１００から機器２００への制御コマンドが複数の制御コマンドから構成される場合、複数の制御コマンドを複数の送信データとして送信するとしてもよい。このとき、複数の送信データのヘッダにフラグメントのフラグ、フラグメントの番号等を付与して送信する。送信データを受信した機器２００は、ヘッダにフラグメントのフラグが立っている場合、制御コマンドが複数の送信データから構成されるため、複数の送信データを受信してから制御コマンドを実行する。このとき、すべての送信データに暗号化及びＭＡＣを生成した場合において、複数の送信データのうち、いずれかのＭＡＣ検証が成功しなかったときには、制御コマンドを実行しない。また、複数の送信データのうち、いずれかのＭＡＣ検証が成功しなかった場合に、以降のフラグメントフラグの付与された送信データのＭＡＣ検証をせずに送信データを破棄するとしてもよい。これにより、受信した機器２００やコントローラ１００の処理を軽くすることができる。
　すべての送信データについてＭＡＣを生成しない場合に、すべての送信データのヘッダ、送信元アドレス、送信先アドレス、及び制御コマンドを結合し、ＭＡＣを生成して、最後の送信データにＭＡＣを付与するとしてもよい。これにより、ＭＡＣ検証を１回実行するだけで、すべての送信データについての完全性を検証することができ、受信した機器２００やコントローラ１００の処理を軽くすることができる。
　ここでは、制御情報ＭＡＣ送信処理について、送信データ２４０４が制御コマンドであるとして説明したが、必ずしも送信データ２４０４が制御コマンドである場合に限られず、例えば、送信データ２４０４が、サーバ３００から機器２００ａに対する通知である場合の例も考えられる。
　この場合には、ステップＳ２６０３の処理は発生せず、コントローラ１００は、サーバ３００から受信した通知を、そのまま送信データ２４０４として利用して、ステップＳ２６０４以降の処理を行う。また、この場合には、ステップＳ２６０８の処理において、機器２００ａは、ＭＡＣ処理に成功した場合に（ステップＳ２６０８：Ｙｅｓ）、ステップＳ２６０９の処理を行う代わりに、復号された通知を記憶する処理を行い、ＭＡＣ処理に成功しなかった場合に（ステップＳ２６０８：Ｎｏ）、復号された通知を記憶する処理を行わない。
　＜１．４　まとめ＞
　本実施の形態は、コントローラと接続する複数機器の中から基準機器を設け、基準機器におけるグループ鍵更新のタイミングで、コントローラが他の機器に対する更新通知を行うことにより、他の機器にグループ鍵の更新を実行させる。これにより、コントローラに接続する複数機器のグループ鍵更新タイミングを合わせることが可能となり、コントローラと各機器とが相互認証及びグループ鍵更新を行っても、コントローラは暗号化した情報の一斉送信を行うことができる。
　また、コントローラと機器との相互認証において、２種類の手続きを採用している。コントローラと機器とが接続する際には、ＰＫＩに基づく公開鍵証明書を用いた相互認証を行う、一方、以後のセッション更新処理時には、共有鍵を用いた相互認証を行う。一般にＰＫＩに基づく相互認証に比較すると、共有鍵を用いた相互認証は処理にかかる負荷が低い。したがって、セッション更新時の相互認証処理として、共有鍵を用いた手続を採用することにより、相互認証に係る処理の負荷を軽減することができる。
　＜２．実施形態２＞
　＜２－１．概要＞
　本実施の形態に係る認証システムは、コントローラが、各機器との間のセッション残り時間を、同時刻においては同様の値を有するように設定する点が異なる。
　以下、説明の便宜上、実施の形態１と同様の構成については、同じ符号を用いる。また、実施の形態１と同様の構成については、説明を省略し、異なる点を重点的に説明する。
　＜２－２．構成＞
　本実施の形態における、認証システム、コントローラ、機器、サーバの構成は、各々実施の形態１における、認証システム１０、コントローラ１００、機器２００ａ～機器２００ｃ、サーバ３００と同様の構成である。しかし、コントローラ１００の機器情報保持部１０２が保持する接続機器管理テーブルのデータ構造が、実施の形態１とは一部異なる。
　図２４は、本実施の形態における接続機器管理テーブル２０００のデータ構造とデータの一例を示した図である。
　接続機器管理テーブル２０００は、接続している機器毎のデータである接続機器管理レコード群を保持しており、各レコードには、機器ＩＤ２０１０、証明書ＩＤ２０２０、共有鍵２０３０、グループ鍵２０４０、セッション鍵２０５０、セッション残り時間２０６０、セッション更新状態２０７０、基準機器２０８０の項目が含まれる。実施の形態１と異なる点は、同一のグループ鍵２０４０を有する機器に対して、セッション残り時間２０６０を共通の値で設定する点である。例えば、図２４では、機器ＩＤ１と機器ＩＤ２とは、同一のグループ鍵である“１１２２３・・・”を保持しており、セッション残り時間についても共に“１３：４０：５０”という同じ値を有している。
　＜２－３．動作＞
　実施の形態１と同様に、本実施の形態においても、認証システム１０は、“機器登録処理”、“セッション更新処理”、“ＰＫＩに基づく相互認証～共有鍵の作成”、“共有鍵を用いた相互認証～セッションに係る情報の作成”、“機器履歴情報送信処理”、“制御情報送信処理”を行う。まず、“共有鍵を用いた相互認証～セッションに係る情報の作成”の手順について説明し、その他の各処理についても、順に、実施の形態１と異なる点を中心に説明する。
　（共有鍵を用いた相互認証～セッションに係る情報の作成）
　実施の形態１と同様に、図２１のシーケンス図におけるステップＳ１２１からステップＳ１３３に沿って、コントローラと機器とは、共有鍵を用いた相互認証を行い、セッションに係る情報である、グループ鍵、セッション鍵、セッション有効期間を作成する。
　ただし、ステップＳ１２８における、コントローラ１００のセッション有効期間の設定方法が実施の形態１とは異なる。
　本実施の形態において、コントローラ１００の認証処理部１０３は、機器が基準機器である場合、予め定めた所定値（例えば、２４時間あるいは７２時間など）を、セッション有効期間として設定する。しかし、機器が基準機器ではない場合、セッション有効期間を以下のように設定する（ステップＳ１２８）。
　コントローラ１００の認証処理部１０３は、機器情報保持部１０２が有する接続機器管理テーブル２０００のセッション残り時間２０６０を参照して、基準機器のセッション残り時間値を取得する。そして、取得した値を、当該機器のセッション有効期間として設定する。
　図２４に示す接続機器管理テーブル２０００のデータを例に説明すると、基準機器ではない機器ＩＤ２の機器に係るセッション有効期間を設定する際、接続機器管理テーブル２０００から基準機器である機器ＩＤ１のセッション残り時間を取得し、機器ＩＤ２のセッション有効期間として設定する。
　このように、基準機器ではない機器のセッション有効期間を、当該セッション有効期間の設定時点における、基準機器のセッション残り期間に合わせて設定することにより、基準機器と、基準機器以外の機器とが、近似するセッション残り時間を有することとなる。
　（機器登録処理）
　実施の形態１と同様に、図１２のシーケンス図における、ステップＳ１０１からステップＳ１０７に沿って、コントローラと機器とは、接続要求、ＰＫＩに基づく相互認証～共有鍵の作成、共有鍵を用いた相互認証～セッションに係る情報の作成、各コントローラ及び機器の登録を行う。
　上述の“共有鍵を用いた相互認証～セッションに係る情報の作成”の手順に記載のとおり、ステップＳ１０３において、基準機器ではない機器のセッション有効期間は、基準機器のセッション残り時間が設定される。
　ステップＳ１０４において、機器側が登録するセッション有効期間は、機器が基準機器であるかないかに関わらず、コントローラ１００より受信したセッション有効期間をセッション残り時間として登録する点は、実施の形態１と同様である。
　ステップＳ１０６において、コントローラが、基準機器ではない機器の機器登録を行う際、セッション残り期間の項目は、基準機器のセッション残り時間を共有する形で登録してもよいし、ステップＳ１０３において設定したセッション有効期間をセッション残り時間として登録してもよい。いずれの形式で登録する場合においても、図１２のシーケンス図におけるステップＳ１０３とステップＳ１０４及びステップＳ１０６は、間をおかずに実施されるものであり、コントローラ１００の接続機器管理テーブル２０００に設定する基準機器と基準機器ではない機器に係るセッション残り時間、及び機器側の接続コントローラ管理テーブル１１００に設定するセッション残り時間は、近似値を有することとなる。
　（セッション更新処理）
　図２５及び図２６は、機器とコントローラとのそれぞれにおける、本実施形態でのセッション更新処理の手順の一例を示したフローチャート図であり、図２７は、機器とコントローラとのやりとりを含む、セッション更新処理の手順の一例を示すシーケンス図である。
　図２５及び図２６のフローチャートに沿って、機器及びコントローラのそれぞれにおける処理の概要を説明した後、図２７のシーケンス図に沿って、機器とコントローラとのやりとりを含む処理の詳細について説明する。
　まず、図２５のフローチャートに沿って、機器におけるセッション更新処理の概要について説明する。
　機器は、コントローラとの間で設定しているセッション残り時間を監視し、予め定めた所定値以下であるか否かを確認する（ステップＳ３０１０）。セッション残り時間が所定値より大きい場合（ステップＳ３０１０のＮＯ）、監視を続ける。
　セッション残り時間が予め定めた所定値以下である場合（ステップＳ３０１０のＹＥＳ）、機器はセッション更新を行うために、コントローラに対して、セッション更新要求を送信する（ステップＳ３０２０）。
　そして、“共有鍵を用いた相互認証～セッションに係る情報の作成”のサブルーチンを実行することで、コントローラと共有鍵を用いた相互認証を行った後、セッションに係る情報である、グループ鍵及びセッション鍵の作成、セッション有効期間の設定を行う（ステップＳ３０３０）。
　ステップＳ３０３０のサブルーチンの戻り値が「正常」である場合（ステップＳ３０４０のＹＥＳ）、機器は、ステップＳ３０３０にて作成した新たなセッションに係る情報を、セッション更新情報として登録する（ステップＳ３０５０）。
　一方、ステップＳ３０３０のサブルーチンの戻り値が「エラー」である場合（ステップＳ３０４０のＮＯ）、セッションの更新を行わずに、セッション更新処理を終了する。
　次に、図２６のフローチャートに沿って、コントローラにおけるセッション更新処理の概要について説明する。
　コントローラは、機器からのセッション更新要求を待ち受ける（ステップＳ３１１０）。受信しなければ（ステップＳ３１１０のＮＯ）、機器からのセッション更新要求を待ち続ける。
　コントローラは機器からセッション更新要求を受信すると（ステップＳ３１１０のＹＥＳ）、“共有鍵を用いた相互認証～セッションに係る情報の作成”のサブルーチンを実行することで、機器と共有鍵を用いた相互認証を行った後、セッションに係る情報である、グループ鍵、セッション鍵、セッション有効期間の設定を行う（ステップＳ３１２０）。
　ステップＳ３１３０のサブルーチンの戻り値が「正常」である場合（ステップＳ３１３０のＹＥＳ）、コントローラは、ステップＳ３１２０にて作成した新たなセッションに係る情報を、セッション更新情報として登録する（ステップＳ３１４０）。
　一方、ステップＳ３１２０のサブルーチンの戻り値が「エラー」である場合（ステップＳ３１３０のＮＯ）、当該セッション更新を実行中の機器とのセッション更新は行わない。
　そして、他にセッションを更新していない機器が存在する場合（ステップＳ３１５０のＹＥＳ）、最初のステップに戻り、当該セッション未更新機器からのセッション更新要求を待ち受ける（ステップＳ３１１０）。
　全ての機器について、セッション更新処理が完了した場合（ステップＳ３１５０のＮＯ）、セッション更新処理を終了する。
　ここからは、図２７のシーケンス図に沿って、実施の形態１との差分を中心に、機器とコントローラとのやりとりを含めて説明する。機器については、一例として、機器２００ａが基準機器であり、機器２００ｂが基準機器以外の機器であるとする。
　機器の機器管理部２０１は、セッション残り時間が所定の閾値以下になった時点で、認証処理部２０４にセッション更新を指示する。指示を受付けた認証処理部２０４は、通信部２０６を介して、セッション更新要求をコントローラ１００に送信する（ステップＳ２０２、ステップＳ２０７）。
　ここで、本実施の形態において、基準機器以外の機器は、基準機器が保持するセッション残り時間と近似のセッション残り時間を有している。したがって、ステップＳ２０２とステップＳ２０７とが近似するタイミングで実施されることにより、コントローラと各機器との間のグループ鍵更新は同じようなタイミングで実施されることとなる。
　“ＰＫＩに基づく相互認証～共有鍵の作成”、“機器履歴情報送信処理”、“制御情報送信処理”については、実施の形態１と同様であるため、説明を省略する。
　＜２－４．まとめ＞
　本実施の形態に係る認証システムでは、基準機器以外のセッション有効期間を、当該セッション有効期間設定時点における基準機器のセッション残り時間に基づき設定することで、基準機器と基準機器以外の機器とが、セッション残り時間として近似する値を有する。したがって、各機器が当該セッション残り時間に基づきセッション更新処理を行うことで、グループ鍵の更新を近似するタイミングで実施することとなり、コントローラと各機器とが相互認証及びグループ鍵更新を行っても、コントローラは暗号化した情報の一斉送信を行うことができる。
　＜３．実施形態３＞
　＜３－１．概要＞
　本実施の形態に係る認証システムは、コントローラと各機器とが、現在使用するためのグループ鍵と更新後に使用するためのグループ鍵との２種類のグループ鍵を保持する点が異なる。
　以下、説明の便宜上、上記実施の形態と同様の構成については、同じ符号を用いる。また、上記実施の形態と同様の構成については、説明を省略し、異なる点を重点的に説明する。
　＜３－２．構成＞
　本実施の形態における、認証システム、コントローラ、機器、サーバの構成は、各々実施の形態２における、認証システム１０、コントローラ１００、機器２００ａ～機器２００ｃ、サーバ３００と同様の構成である。しかし、コントローラ１００の機器情報保持部１０２が保持する接続機器管理テーブルのデータ構成の一部、及び機器の機器情報保持部２０３が保持する接続コントローラ管理テーブルのデータ構造の一部が、上記実施の形態とは異なる。
　図２８は、本実施の形態において、コントローラ１００の機器情報保持部１０２が有する接続機器管理テーブル３０００のデータ構造及びデータの一例を示した図である。
　接続機器管理テーブル３０００は、接続している機器毎のデータである接続機器管理レコード群を格納しており、各レコードには、機器ＩＤ３０１０、証明書ＩＤ３０２０、共有鍵３０３０、グループ鍵（現）３０４０、グループ鍵（新）３０５０、セッション鍵３０６０、セッション残り時間３０７０、セッション更新状態３０８０、基準機器３０９０の項目が含まれる。グループ鍵については、グループ鍵（現）とグループ鍵（新）の２つの項目を有している。
　図２９は、本実施の形態において、機器の機器情報保持部２０３が有する接続コントローラ管理テーブル３１００のデータ構造及びデータの一例を示した図である。
　接続コントローラ管理テーブル３１００は、接続しているコントローラのデータである接続コントローラ管理レコード群を格納しており、各レコードには、コントローラＩＤ３１１０、証明書ＩＤ３１２０、共有鍵３１３０、グループ鍵（現）３１４０、グループ鍵（新）３１５０、セッション鍵３１６０、セッション残り時間３１７０の項目が含まれる。グループ鍵については、接続機器管理テーブル３０００と同様に、グループ鍵（現）とグループ鍵（新）の２つの項目を有している。
　ここで、コントローラが各機器に対して一斉送信する情報の暗号化は、コントローラ及び各機器が、グループ鍵（現）として保持している暗号鍵を用いて行われる。一方、グループ鍵（新）は、コントローラと基準機器との間のセッション更新処理において、新たに作成したグループ鍵を保持する項目である。
　＜３－３．動作＞
　実施の形態２と同様に、本実施の形態における認証システム１０は、“機器登録処理”、“セッション更新処理”、“ＰＫＩに基づく相互認証～共有鍵の作成”、“共有鍵を用いた相互認証～セッションに係る情報の作成”、“機器履歴情報送信処理”、“制御情報送信処理”を行う。
　（機器登録処理）
　実施の形態２と同様に、図１２のシーケンス図における、ステップＳ１０１からステップＳ１０７に沿って、コントローラと機器とは、接続要求、ＰＫＩに基づく相互認証～共有鍵の作成、共有鍵を用いた相互認証～セッションに係る情報の作成、各コントローラ及び機器の登録を行う。
　ただし、ステップＳ１０４において、機器２００ａの認証処理部２０４が、機器管理部２０１を介して、接続コントローラ管理テーブル３１００を登録する際、ステップＳ１０３において作成したグループ鍵の情報は、グループ鍵（現）３１４０の項目に登録する（ステップＳ１０４）。
　また、ステップＳ１０６において、コントローラ１００の機器管理部１０１が、接続機器管理テーブル３０００を登録する際も、グループ鍵の情報は、グループ鍵（現）３０４０の項目に登録する（ステップＳ１０６）。
　（セッション更新処理）
　図３０及び図３１は、機器とコントローラとのそれぞれにおける、本実施形態のセッション更新処理の手順の一例を示したフローチャート図であり、図３２は、機器とコントローラとのやりとりを含む、セッション更新処理の手順の一例を示すシーケンス図である。
　図３０及び図３１のフローチャートに沿って、機器及びコントローラにおける処理の概要を説明した後、図３２のシーケンス図に沿って、機器とコントローラとのやりとりを含む処理の詳細について説明する。
　まず、図３０のフローチャートに沿って、機器におけるセッション更新処理の概要について説明する。
　機器は、コントローラとの間で設定しているセッション残り時間を監視し、予め定めた所定値以下であるか否かを確認する（ステップＳ４０１０）。セッション残り時間が所定値より大きい場合（ステップＳ４０１０のＮＯ）、監視を続ける。
　セッション残り時間が予め定めた所定値以下である場合（ステップＳ４０１０のＹＥＳ）、機器はセッション更新を行うために、コントローラに対して、セッション更新要求を送信する（ステップＳ４０２０）。
　そして、“共有鍵を用いた相互認証～セッションに係る情報の作成”のサブルーチンを実行することで、コントローラと共有鍵を用いた相互認証を行った後、セッションに係る情報である、グループ鍵及びセッション鍵の作成、セッション有効期間の設定を行う（ステップＳ４０３０）。
　ステップＳ４０３０のサブルーチンの戻り値が「正常」である場合（ステップＳ４０４０のＹＥＳ）、ステップＳ４０５０に進み、機器は、ステップＳ４０３０にて作成した新たなセッションに係る情報を、セッション更新情報として登録する（ステップＳ４０５０）。
　そして、機器は、コントローラからのグループ鍵更新通知を待ち受ける（ステップＳ４０６０）。グループ鍵更新通知を受信しない場合（ステップＳ４０６０のＮＯ）、受信するまで待ち続ける。
　グループ鍵更新通知を受信した場合（ステップＳ４０６０のＹＥＳ）、現在使用しているグループ鍵と、ステップＳ４０３０にて新たに作成したグループ鍵を入れ替えることで、グループ鍵の更新を行う（ステップＳ４０７０）。
　一方、ステップＳ４０３０のサブルーチンの戻り値が「エラー」である場合（ステップＳ４０４０のＮＯ）、セッション更新を行わずに、セッション更新処理を終了する。
　次に、図３１のフローチャートに沿って、コントローラにおけるセッション更新処理の概要について説明する。
　コントローラは、機器からのセッション更新要求を待ち受ける（ステップＳ４１１０）。受信しなければ（ステップＳ４１１０のＮＯ）、機器からのセッション更新要求を待ち続ける。
　機器からセッション更新要求を受信すると（ステップＳ４１１０のＹＥＳ）、コントローラは、“共有鍵を用いた相互認証～セッションに係る情報の作成”のサブルーチンを実行することで、機器と共有鍵を用いた相互認証を行った後、セッションに係る情報である、グループ鍵及びセッション鍵の作成、セッション有効期間の設定を行う（ステップＳ４１２０）。
　ステップＳ４１２０のサブルーチンの戻り値が「正常」である場合（ステップＳ４１３０のＹＥＳ）、コントローラは、ステップＳ４１２０にて作成した新たなセッションに係る情報を、セッション更新情報として登録する（ステップＳ４１４０）。
　一方、ステップＳ４１２０のサブルーチンの戻り値が「エラー」である場合（ステップＳ４１３０のＮＯ）、当該セッション更新を実行中の機器についてのセッション更新は行わない。
　他にセッションを更新していない機器が存在する場合（ステップＳ４１５０のＹＥＳ）、最初のステップに戻り、当該セッション未更新機器からのセッション更新要求を待ち受ける（ステップＳ４１１０）。
　全ての機器について、セッション更新処理が完了した場合（ステップＳ４１５０のＮＯ）、同一のグループ鍵を使用する機器に対して、グループ鍵更新通知を送信する（ステップＳ４１６０）。
　そして、コントローラ自身も、現在使用しているグループ鍵と、ステップＳ４１２０にて新たに作成したグループ鍵を入れ替えることで、グループ鍵の更新を行う（ステップＳ４１７０）。
　ここからは、図３２のシーケンス図に沿って、実施の形態２との差分を中心に、機器とコントローラとのやりとりを含めて説明する。機器については、一例として、機器２００ａが基準機器であり、機器２００ｂが基準機器以外の機器であるとする。
　本実施の形態では、実施の形態２と同様に、各機器はセッション残り時間に応じて、コントローラに対するセッション更新を要求し、共有鍵を用いた相互認証～セッションに係る情報の作成を行う。そして、機器とコントローラとは、セッション更新情報を登録する。
　ステップＳ３０４及びステップＳ３１０において、各機器の機器管理部２０１は、作成した、セッション鍵、グループ鍵、及びセッション有効時間を、機器情報保持部２０３の保持する、接続コントローラ管理テーブル３１００に登録する。このとき、作成したグループ鍵の情報はグループ鍵（新）３１５０の項目に登録する。
　また、ステップＳ３０５及びステップＳ３０９において、コントローラの機器管理部１０１は、作成した、セッション鍵、グループ鍵、及びセッション有効時間を、機器情報保持部１０２の有する、接続機器管理テーブル３０００に登録する。このとき、作成したグループ鍵の情報はグループ鍵（新）３０５０の項目に登録する。セッション更新状態３０８０については、上述の実施の形態と同様に、基準機器とのセッション更新を行う際に、基準機器以外の機器に係るセッション更新状態３０８０の値を、“未更新”に設定する。そして、基準機器以外の機器とのセッション更新を行う際には“更新済”に更新する。
　そして、コントローラ１００の機器管理部１０１は、接続機器管理テーブル３０００のセッション更新状態３０８０の項目を参照し、“未更新”の機器がないかを確認する。このとき、セッション更新状態の項目が“未更新”の機器が存在する場合、当該機器からのセッション更新要求を待ち受ける。セッション更新状態が“未更新”である機器が存在しない場合、コントローラの機器管理部１０１は、同一グループ鍵を用いて暗号通信を行う全ての機器に対して、グループ鍵更新通知を行う（ステップＳ３１１）。
　機器の機器管理部２０１は、グループ鍵更新通知を受信すると、接続コントローラ管理テーブル３１００のグループ鍵（新）３１５０が保持する値で、グループ鍵（現）３１４０の値を上書き更新し、グループ鍵（新）３１５０に設定されている値は削除する。
　コントローラ１００の機器管理部１０１も同様に、接続機器管理テーブル３０００のグループ鍵（新）３０５０が保持する値で、グループ鍵（現）３０４０を上書き更新した上で、グループ鍵（新）３０５０に設定されている値は削除する。
　“ＰＫＩに基づく相互認証～共有鍵の作成”、“共有鍵を用いた相互認証～セッションに係る情報の作成”、“機器履歴情報送信処理”、“制御情報送信処理”については、上述の実施の形態２と同様であるため、説明を省略する。
　ただし、コントローラが機器に一斉送信する情報の暗号化に用いる暗号鍵は、コントローラ及び機器の各々が「グループ鍵（現）」として保持する暗号鍵を用いる。
　＜３－４．まとめ＞
　本実施の形態に係る認証システムでは、コントローラと各機器とのセッション更新処理において新たに作成したグループ鍵を、暗号通信に用いるグループ鍵とは別の場所に保持する。そして、コントローラと接続する全ての機器との間でセッション更新処理を行った時点で、コントローラが機器に対するグループ鍵更新通知を行い、コントローラと各機器とは、グループ鍵の切り替えを実施する。こうすることにより、コントローラと複数の機器とが同じタイミングでグループ鍵の更新を行うことが可能となり、コントローラと各機器とが相互認証及びグループ鍵更新を行っても、コントローラは暗号化した情報の一斉送信を行うことができる。
　＜４．変形例＞
　以上、本開示に係る認証方法を用いた認証システムについて、実施の形態に基づき説明したが、以下のように変形することも可能であり、本開示は上述した実施の形態で示した通りの認証方法に限られないことは勿論である。
　（１）上記実施の形態において、コントローラ及び機器は１つのネットワークに接続する。当該ネットワークは、ホームエリアネットワークであってもよいし、その他のエリアネットワークであってもよい。
　（２）上記実施の形態では、１つのコントローラに対して、１つのグループ鍵を設定しているが、複数のグループ鍵を設定してもよい。このとき、同じグループ鍵を用いる機器毎に、１つの基準機器を設定する。
　（３）上記実施の形態において、コントローラと基準機器との接続が削除された場合、コントローラは、機器情報保持部の保持する接続機器管理テーブルから、別の機器を抽出し基準機器として設定する。このとき、基準機器は、常に電源が入っている機器を指定するとしてもよい。例えば、冷蔵庫などの常に電源が入って動作している機器を指定してもよい。
　（４）上記実施の形態における共有鍵を用いた相互認証では、共有鍵と乱数とを用いるチャレンジレスポンス認証を行っているが、これに限定するわけではない。例えば、ＲＦＣ５１９１　Ｐｒｏｔｏｃｏｌ　ｆｏｒ　Ｃａｒｒｙｉｎｇ　Ａｕｔｈｅｎｔｉｃａｔｉｏｎ　ｆｏｒ　Ｎｅｔｗｏｒｋ　Ａｃｃｅｓｓ（ＰＡＮＡ）の認証方式を用いてもよい。ＲＦＣ５１９１については、非特許文献３に記載されている一般的な技術を用いるため、説明は省略する。
　ＲＦＣ５１９１を用いる場合において、更にＥＡＰ－ＰＳＫを用いて認証を行うとしてもよい。また、セッション鍵は、ＥＡＰ－ＰＳＫのネゴシエーションの結果として導出されるＥＭＳＫを用いて導出するとしてもよい。更に、このときの鍵導出関数として、ＨＭＡＣ＿ＳＨＡ２＿２５６を用いてもよい。
　（５）上記実施の形態では、機器登録処理時及びセッション更新処理時において、コントローラがグループ鍵を作成し、機器に対して配信している。しかし、これに限定するものではなく、コントローラと基準機器との間でＥＣＤＨやＤＨ（Ｄｉｆｆｉｅ－Ｈｅｌｌｍａｎ）による鍵交換を行うことで、グループ鍵を共有してもよい。
　また、コントローラと基準機器とのそれぞれが、乱数を生成し、生成した乱数を共有鍵で暗号化して相手に送信する。そして、受信した暗号化乱数を共有鍵で復号し、自らが生成した乱数と復号した乱数との排他的論理和演算した結果をグループ鍵としてもよい。
　これらは、コントローラと各機器とにおけるセッション鍵の作成手順として用いてもよい。
　（６）本開示に係るコントローラは、コントローラのための専用機器であってもよい。また、家庭に設置される分電盤であってもよい。その他のテレビなどのＡＶ機器であってもよいし、家電機器などであってもよい。
　（７）コントローラは、接続する機器の消費電力量や蓄電池の電力量、太陽光発電の発電量を表示する機能を有していてもよい。
　（８）本開示に係るコントローラと機器との間の通信方式は、Ｅｔｈｅｒｎｅｔ（登録商標）、Ｗｉ－Ｆｉ（Ｗｉｒｅｌｅｓｓ　Ｆｉｄｅｌｉｔｙ）、特定小電力無線、電力線通信、Ｂｌｕｅｔｏｏｔｈ（登録商標）であってもよい。
　（９）上記実施の形態１では、セッション更新処理において、セッション未更新の機器が存在した場合、当該機器に対してセッション更新通知を送信することで、機器にセッション更新を開始させている。ここで、当該機器の電源が入っていない場合、コントローラは当該機器に対して、定期的にセッション更新通知を送信するとしてもよい。
　（１０）上記実施の形態１では、セッション更新処理において、セッション未更新の機器が存在した場合、当該機器に対してセッション更新通知を送信することで、機器にセッション更新を開始させている。ここで、当該機器において実行中の処理がある等により、機器が、セッション更新処理の開始が不可であると判断する場合、当該機器からコントローラに対して、セッション更新の延期時間を通知して、当該延期時間の経過後にセッション更新処理を行うとしてもよい。
　（１１）上記実施の形態では、接続機器管理テーブルや接続コントローラ管理テーブルが有するセッションの残り時間でセッションの有効期限を管理している。しかし、これに限定するものではなく、セッションの開始日時やセッションの終了日時で管理するとしてもよい。例えば、セッションの開始日時で管理する場合、所定のセッション有効期間を予め設定し、セッション開始日時にセッション有効期間を追加した日時と、現在の日時とを比較し、セッションを更新するかを判断してもよい。また、例えば、セッションの終了日時で管理する場合、現在の日時とセッションの終了日時とを比較し、セッションを更新するかを判断してもよい。
　（１２）上記実施の形態では、セッション更新処理において、機器側で、セッション残り時間に基づき、セッション更新のタイミングを判断し、コントローラにセッション更新要求を送信することで、セッション更新を開始している。しかし、これに限定するものではなく、コントローラ側で、セッション残り時間に基づき、セッション更新のタイミングを判断し、セッション更新を開始するとしてもよい。
　（１３）上記実施の形態では、機器とコントローラとの間で、１対１の暗号化ユニキャスト通信を行うためのセッション鍵を共有している。しかし、セッション鍵を共有せずに、機器とコントローラ間の暗号化通信の全てをグループ鍵で行うとしてもよい。
　（１４）上記実施の形態では、セッション更新処理において、グループ鍵とセッション鍵との両方を更新しているが、これに限定するものではなく、セッション更新処理時において、グループ鍵のみまたはセッション鍵のみを更新するとしてもよい。
　（１５）上記実施の形態における認証システムに係る装置である、コントローラ、機器、サーバは、具体的には、プロセッサ、メモリなどから構成される。メモリには、コンピュータプログラムが記録されている。プロセッサが、メモリに記録されているコンピュータプログラムにしたがって動作することにより、各装置はその機能を達成する。ここで、コンピュータプログラムは、所定の機能を達成するために、コンピュータに対する指令を示す命令コードが複数個組み合わされて構成されたものである。
　（１６）上記実施の形態における認証システムに係る各装置を構成する構成要素の一部または全部は、１個のシステムＬＳＩ（Ｌａｒｇｅ　Ｓｃａｌｅ　Ｉｎｔｅｇｒａｔｉｏｎ：大規模集積回路）から構成されているとしてもよい。上記の各装置を構成する構成要素の各部は、個別に１チップ化されていても良いし、一部または全てを含むように１チップ化されてもよい。
　また、ここでは、システムＬＳＩと記述したが、集積度の違いにより、ＩＣ（Ｉｎｔｅｇｒａｔｅｄ　Ｃｉｒｃｕｉｔ）、ＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。また、集積回路化の手法はＬＳＩに限るものではなく、専用回路または汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Ｆｉｅｌｄ　Ｐｒｏｇｒａｍｍａｂｌｅ　Ｇａｔｅ　Ａｒｒａｙ）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用しても良い。
　さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。バイオ技術の適用等が可能性としてありえる。
　（１７）上記実施の形態における認証システムに係る各装置を構成する構成要素の一部または全部は、各装置に脱着可能なＩＣカードまたは単体のモジュールから構成されているとしてもよい。このＩＣカードまたはこのモジュールは、耐タンパ性を有するとしてもよい。
　（１８）本開示は、上記に示す方法であるとしてもよい。また、これらの方法をコンピュータにより実現するコンピュータプログラムであるとしてもよいし、前記コンピュータプログラムからなるデジタル信号であるとしてもよい。これらのコンピュータプログラムをメモリに記憶し、プロセッサにより実行するとしてもよい。
　また、本開示は、前記コンピュータプログラムまたは前記デジタル信号をコンピュータ可読記録媒体、例えば、フレキシブルディスク、ハードディスク、ＣＤ－ＲＯＭ、ＭＯ、ＤＶＤ、ＤＶＤ－ＲＯＭ、ＤＶＤ－ＲＡＭ、ＢＤ（Ｂｌｕ－ｒａｙ（登録商標）　Ｄｉｓｃ）、半導体メモリなどに記録したものとしてもよい。また、これらの記録媒体に記録されている前記デジタル信号であるとしてもよい。
　また、本開示は、前記コンピュータプログラムまたは前記デジタル信号を、電気通信回線、無線または有線通信回線、インターネットを代表とするネットワーク、データ放送等を経由して伝送するものとしてもよい。
　また、本開示は、プロセッサとメモリを備えたコンピュータシステムであって、前記メモリは、上記コンピュータプログラムを記録しており、前記プロセッサは、前記コンピュータプログラムにしたがって動作するとしてもよい。
　また、前記コンピュータプログラムまたは前記デジタル信号を前記記録媒体に記録して移送することにより、または前記コンピュータプログラムまたは前記デジタル信号を前記ネットワーク等を経由して移送することにより、独立した他のコンピュータシステムにより実施するとしてもよい。
　（１９）本開示は、上記各実施の形態及び上記各変形例を部分的に組み合わせるとしてもよい。
　＜５．補足＞
　以下、更に本開示に係る認証方法の一実施形態とその効果について説明する。
　（ａ）本開示に係る認証方法は、コントローラと第１機器と第２機器とがグループ鍵を共有し、前記コントローラが前記第１機器と前記第２機器とに対して、前記グループ鍵を用いて暗号化した情報の一斉送信を行う認証システムにおける、前記コントローラと前記第１機器及び前記第２機器との認証方法であって、前記コントローラと前記第１機器とが相互認証を実行し、グループ鍵を作成して共有すると共に、前記第１機器を基準機器として設定する第１相互認証ステップと、前記コントローラと前記第２機器とが相互認証を実行し、前記第１相互認証ステップで作成したグループ鍵を前記第２機器にも共有させる第２相互認証ステップと、前記第２相互認証ステップの後に、前記コントローラと前記基準機器である前記第１機器とが再び相互認証を実行し、前記グループ鍵を更新し、更新後のグループ鍵を共有する第３相互認証ステップと、前記コントローラと前記基準機器とが前記グループ鍵を更新するグループ鍵更新タイミングにおいて、前記コントローラと前記基準機器ではない前記第２機器とが相互認証を実行し、前記更新後のグループ鍵を前記第２機器にも共有させる第４相互認証ステップとを含むことを特徴とする。
　これにより、コントローラに接続する機器の中から基準機器を設定し、当該基準機器におけるグループ鍵更新のタイミングに基づき、他の機器がグループ鍵の更新を行うことで、複数の機器間におけるグループ鍵更新のタイミングを合わせることが可能となり、コントローラと各機器とが相互認証及びグループ鍵更新を行っても、コントローラは暗号化した情報の一斉送信を行うことができる。
　（ｂ）上記（ａ）に係る認証方法において、前記コントローラと前記第１機器と前記第２機器とは、１つのホームエリアネットワークに接続することとしてもよい。
　これにより、ホームエリアネットワークに接続するコントローラとそれぞれの機器とのグループ鍵更新タイミングを合わせることが可能となり、コントローラと各機器とが相互認証及びグループ鍵更新を行っても、コントローラは暗号化した情報の一斉送信を行うことができる。
　（ｃ）上記（ａ）に係る認証方法において、更に、前記コントローラは、前記基準機器である前記第１機器と前記グループ鍵を更新して共有すると、当該更新後のグループ鍵を共有していない前記第２機器に対して、グループ鍵更新通知を送信するグループ鍵更新通知ステップを含み、前記グループ鍵更新タイミングは、前記第２機器が、前記グループ鍵更新通知を受信するタイミングであることとしてもよい。
　これにより、コントローラと基準機器との間でグループ鍵を更新して以降において、当該更新後のグループ鍵を共有していない機器が、コントローラからグループ鍵更新通知を受信しグループ鍵を更新することで、コントローラに接続する複数機器のグループ鍵更新タイミングを合わせることができる。
　（ｄ）上記（ａ）に係る認証方法において、前記第１相互認証ステップにおいて、更に、前記コントローラと前記第１機器とは第１セッション期間を設定し、前記第２相互認証ステップにおいて、更に、前記コントローラと前記第２機器とは、前記第１セッション期間と前記第１セッション期間設定時点からの経過期間とに基づく第２セッション期間を設定し、前記コントローラと前記第１機器とは、前記第１セッション期間設定時点からの経過期間と前記第１セッション期間とに基づき、前記第３相互認証ステップを開始し、前記グループ鍵更新タイミングは、前記第２セッション期間設定時点からの経過期間と前記第２セッション期間とに基づくタイミングであることとしてもよい。
　これにより、コントローラと基準機器以外の機器との間のセッション期間は、コントローラと基準機器との間のセッション残り期間に基づき設定され、コントローラと接続する各機器とが当該セッション期間に基づきグループ鍵更新を行うことで、コントローラと接続する複数機器のグループ鍵更新タイミングを合わせることができる。
　（ｅ）上記（ａ）に係る認証方法において、前記コントローラは、コントローラ自身の秘密鍵と公開鍵証明書とを所有し、前記第１機器は、第１機器自身の秘密鍵と公開鍵証明書とを所有し、更に、前記コントローラと前記第１機器とが、第１共有鍵を作成して共有する第１共有鍵共有ステップを含み、前記第１相互認証ステップにおける相互認証は、公開鍵基盤に基づき、互いの所有する前記公開鍵証明書を用いて相互認証を行う公開鍵認証であり、前記第３相互認証ステップにおける相互認証は、前記第１共有鍵を用いて相互認証を行う共有鍵認証であることとしてもよい。
　ここでは、例えば、コントローラと機器とが接続する際には、ＰＫＩに基づく公開鍵証明書を用いた相互認証を行う一方で、以降のセッション更新処理時には、共有鍵を用いた相互認証を行う。一般にＰＫＩに基づく相互認証に比較すると、共有鍵を用いた相互認証は処理にかかる負荷が低いことから、共有鍵を用いた手続を採用することにより、相互認証に係る処理の負荷を軽減することができる。
　（ｆ）上記（ｅ）に係る認証方法において、前記第１共有鍵共有ステップは、前記コントローラと前記第１機器とが鍵交換により第１共有鍵を共有し、前記共有鍵認証は、前記コントローラと前記第１機器とが、互いに作成した乱数と前記第１共有鍵とを用いて行うチャレンジレスポンス認証により相互認証することとしてもよい。
　これにより、コントローラと機器とは共有鍵と乱数とを用いたチャレンジレスポンス認証により、互いの正当性を確認することができる。
　（ｇ）上記（ｅ）に係る認証方法において、前記第２機器は、第２機器自身の秘密鍵と公開鍵証明書とを所有し、更に、前記コントローラと前記第２機器とが、第２共有鍵を作成して共有する第２共有鍵共有ステップを含み、前記第２相互認証ステップにおける相互認証は、公開鍵基盤に基づき、互いの所有する前記公開鍵証明書を用いて相互認証を行う公開鍵認証であり、前記第４相互認証ステップにおける相互認証は、前記第２共有鍵を用いて相互認証を行う共有鍵認証であることとしてもよい。
　これにより、コントローラは、コントローラと接続する全ての機器と、ＰＫＩに基づく相互認証と、共有鍵を用いる相互認証との２種類の手続きを組み合わせて行うことで、相互認証に係る処理の負荷を軽減することができる。
　（ｈ）本開示に係る認証システムは、コントローラと第１機器と第２機器とがグループ鍵を共有し、前記コントローラが前記第１機器と前記第２機器とに対して、前記グループ鍵を用いて暗号化した情報の一斉送信を行う認証システムであって、前記コントローラと前記第１機器とが相互認証を実行し、グループ鍵を作成して共有すると共に、前記第１機器を基準機器として設定する第１相互認証手段と、前記コントローラと前記第２機器とが相互認証を実行し、前記第１相互認証ステップで作成したグループ鍵を、前記第２機器にも共有させる第２相互認証手段と、前記第２相互認証ステップの後に、前記コントローラと前記基準機器である前記第１機器とが再び相互認証を実行し、前記グループ鍵を更新し、更新後のグループ鍵を共有する第３相互認証手段と、前記コントローラと前記基準機器とが前記グループ鍵を更新するグループ鍵更新タイミングにおいて、前記コントローラと前記基準機器ではない前記第２機器とに相互認証を実行させ、前記更新後のグループ鍵を、前記第２の機器にも共有させる第４相互認証手段とを備えることを特徴とする。
　これにより、コントローラに接続する機器の中から基準機器を設定し、当該基準機器におけるグループ鍵更新のタイミングに基づき、他の機器がグループ鍵の更新を行うことで、複数の機器間におけるグループ鍵更新のタイミングを合わせることが可能となり、コントローラと各機器とが相互認証及びグループ鍵更新を行っても、コントローラは暗号化した情報の一斉送信を行うことができる。
　本開示に係る認証方法は、コントローラが接続する複数機器に対してグループ鍵を用いて暗号化した情報の一斉送信を行うネットワークシステムにおいて、コントローラと各機器との相互認証及びグループ鍵更新等に活用することができる。
１０　認証システム
１００　コントローラ
１０１　機器管理部
１０２　機器情報保持部
１０３　認証処理部
１０４　認証情報保持部
１０５　通信部
２００ａ，２００ｂ，２００ｃ　機器
２０１　機器管理部
２０２　機器履歴保持部
２０３　機器情報保持部
２０４　認証処理部
２０５　認証情報保持部
２０６　通信部
３００　サーバ
３０１　機器情報管理部
３０２　機器情報保持部
３０３　ＣＲＬ管理部
３０４　ＣＲＬ保持部
３０５　通信部
４００　ホームエリアネットワーク
５００　ネットワーク
１０００　接続機器管理テーブル
１１００　接続コントローラ管理テーブル
１３００　機器情報管理テーブル
２０００　接続機器管理テーブル
３０００　接続機器管理テーブル
３１００　接続コントローラ管理テーブル

Claims (9)

  1. 　コントローラと第１機器と第２機器とがグループ鍵を共有し、前記コントローラが前記第１機器と前記第２機器とに対して、前記グループ鍵を用いて暗号化した情報の一斉同報通信を行う認証システムにおける、前記コントローラと前記第１機器及び前記第２機器との認証方法であって、
    　前記コントローラと前記第１機器とが相互認証を実行し、グループ鍵を作成して共有すると共に、前記第１機器を基準機器として設定する第１相互認証ステップと、
    　前記コントローラと前記第２機器とが相互認証を実行し、前記第１相互認証ステップで作成したグループ鍵を前記第２機器にも共有させる第２相互認証ステップと、
    　前記第２相互認証ステップの後に、前記コントローラと前記基準機器である前記第１機器とが再び相互認証を実行し、前記グループ鍵を更新し、更新後のグループ鍵を共有する第３相互認証ステップと、
    　前記コントローラと前記基準機器とが前記グループ鍵を更新するグループ鍵更新タイミングにおいて、前記コントローラと前記基準機器ではない前記第２機器とが相互認証を実行し、前記更新後のグループ鍵を前記第２機器にも共有させる第４相互認証ステップと、
    　前記グループ鍵を用いて送信データを暗号化して暗号化データを生成し、当該送信データと、ヘッダと、送信元アドレスと、送信先アドレスとからＭＡＣを生成し、当該暗号化データと、当該ヘッダと、当該送信元アドレスと、当該送信先アドレスと、当該ＭＡＣとを含むメッセージの前記一斉同報通信を行う暗号化ステップとを含む
    　ことを特徴とする認証方法。
  2. 　前記第１機器と前記第２機器とのうちの少なくとも１つの機器が、前記コントローラから前記メッセージを受信し、当該メッセージに含まれる前記暗号化データを復号し、当該メッセージに含まれるＭＡＣを検証する復号化ステップを更に含む
    　ことを特徴とする請求項１記載の認証方法。
  3. 　前記暗号化ステップは、
    　前記送信データが複数ある場合には、当該複数の送信データそれぞれについて、前記ヘッダに所定のフラグを付与して、前記暗号化データの生成と、前記ＭＡＣの生成と、前記一斉同報通信とを行い、
    　前記復号化ステップは、
    　前記ヘッダに前記所定のフラグが付与されたメッセージを複数受信する場合において、当該複数のメッセージのうちの一のメッセージに対する前記ＭＡＣの検証に成功しなかったとき、当該複数のメッセージの中に未だ前記暗号化データの復号が実行されていないメッセージが存在すれば、当該復号が実行されていないメッセージに対する前記復号の実行を抑制する
    　ことを特徴とする請求項２記載の認証方法。
  4. 　前記送信データは、前記第１機器と前記第２機器とのうちの少なくとも１つの機器に対する制御コマンド、又は、前記第１機器と前記第２機器とのうちの少なくとも１つの機器に対する通知のいずれかである
    　ことを特徴とする請求項１記載の認証方法。
  5. 　前記グループ鍵を用いて前記第１機器と前記第２機器とのうちの少なくとも１つの機器についての履歴情報を暗号化して履歴情報暗号化データを生成し、当該履歴情報暗号化データと、ヘッダと、送信元アドレスと、送信先アドレスとからＭＡＣを生成し、当該ＭＡＣと当該履歴情報暗号化データとを含めて暗号化した履歴情報を生成し、当該ヘッダと、当該送信元アドレスと、当該送信先アドレスとを利用して、当該暗号化した履歴情報を、当該１つの機器から前記コントローラへ送信する履歴情報暗号化ステップを更に含む
    　ことを特徴とする請求項１記載の認証方法。
  6. 　前記暗号化ステップは、前記暗号化データの生成と、前記ＭＡＣの生成とを、ＡＥＳ－ＣＣＭの認証付暗号化法を利用して行う
    　ことを特徴とする請求項１記載の認証方法。
  7. 　コントローラと第１機器と第２機器とがグループ鍵を共有し、前記コントローラが前記第１機器と前記第２機器とに対して、前記グループ鍵を用いて暗号化した情報の一斉同報通信を行う認証システムであって、
    　前記コントローラと前記第１機器とが相互認証を実行し、グループ鍵を作成して共有すると共に、前記第１機器を基準機器として設定する第１相互認証手段と、
    　前記コントローラと前記第２機器とが相互認証を実行し、前記第１相互認証手段によって作成されたグループ鍵を前記第２機器にも共有させる第２相互認証手段と、
    　前記第２相互認証手段による前記共有が行われた後に、前記コントローラと前記基準機器である前記第１機器とが再び相互認証を実行し、グループ鍵を更新し、更新後のグループ鍵を共有する第３相互認証手段と、
    　前記コントローラと前記基準機器とが前記グループ鍵を更新するグループ鍵更新タイミングにおいて、前記コントローラと前記基準機器ではない前記第２機器とが相互認証を実行し、前記更新後のグループ鍵を前記第２機器にも共有させる第４相互認証手段と、
    　前記グループ鍵を用いて送信データを暗号化して暗号化データを生成し、当該送信データと、ヘッダと、送信元アドレスと、送信先アドレスとからＭＡＣを生成し、当該暗号化データと、当該ヘッダと、当該送信元アドレスと、当該送信先アドレスと、当該ＭＡＣとを含むメッセージの前記一斉同報通信を行う暗号化手段とを備える
    　ことを特徴とする認証方法。
  8. 　グループ鍵を用いて暗号化した情報の一斉同報通信を行う認証システムで利用されるコントローラであって、
    　第１機器との間で相互認証を実行し、グループ鍵を生成して共有すると共に、前記第１機器を基準機器として設定する第１相互認証手段と、
    　第２機器との間で相互認証を実行し、前記第１相互認証手段によって生成されたグループ鍵を、前記第２機器とも共有する第２相互認証手段と、
    　前記第２相互認証手段による前記共有が行われた後に、前記基準機器である前記第１機器との間で再び相互認証を実行し、グループ鍵を更新し、更新後のグループ鍵を前記第１機器と共有する第３相互認証手段と、
    　前記第３相互認証手段による前記グループ鍵を更新するタイミングにおいて、前記基準機器ではない前記第２機器との間で相互認証を実行し、前記更新後のグループ鍵を、前記第２機器とも共有する第４相互認証手段と、
    　前記グループ鍵を用いて送信データを暗号化して暗号化データを生成し、当該送信データと、ヘッダと、送信元アドレスと、送信先アドレスとからＭＡＣを生成し、当該暗号化データと、当該ヘッダと、当該送信元アドレスと、当該送信先アドレスと、当該ＭＡＣとを含むメッセージの前記一斉同報通信を行う暗号化手段とを備える
    　ことを特徴とするコントローラ。
  9. 　グループ鍵を用いて暗号化した情報の一斉同報通信を行う認証システムで利用される機器であって、
    　前記認証システムを構成するコントローラから、グループ鍵を用いて送信データを暗号化した暗号化データと、ヘッダと、送信元アドレスと、送信先アドレスと、当該送信データ、当該ヘッダ、当該送信元アドレス、及び当該送信先アドレスから生成されたＭＡＣとを含むメッセージを受信し、当該メッセージに含まれる前記暗号化データを復号し、当該メッセージに含まれるＭＡＣを検証する復号化手段を備える
    　ことを特徴とする機器。
PCT/JP2016/000946 2015-05-08 2016-02-23 認証方法及び認証システム Ceased WO2016181586A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
EP16792321.8A EP3297207A1 (en) 2015-05-08 2016-02-23 Authentication method and authentication system
CN201680001228.XA CN106416122A (zh) 2015-05-08 2016-02-23 认证方法和认证系统
JP2017517588A JPWO2016181586A1 (ja) 2015-05-08 2016-02-23 認証方法及び認証システム
US15/391,901 US20170111357A1 (en) 2015-05-08 2016-12-28 Authentication method and authentication system

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US201562158906P 2015-05-08 2015-05-08
US62/158,906 2015-05-08
JP2016-007554 2016-01-19
JP2016007554 2016-01-19

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US15/391,901 Continuation US20170111357A1 (en) 2015-05-08 2016-12-28 Authentication method and authentication system

Publications (1)

Publication Number Publication Date
WO2016181586A1 true WO2016181586A1 (ja) 2016-11-17

Family

ID=57247833

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2016/000946 Ceased WO2016181586A1 (ja) 2015-05-08 2016-02-23 認証方法及び認証システム

Country Status (5)

Country Link
US (1) US20170111357A1 (ja)
EP (1) EP3297207A1 (ja)
JP (1) JPWO2016181586A1 (ja)
CN (1) CN106416122A (ja)
WO (1) WO2016181586A1 (ja)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6359212B1 (ja) * 2017-07-12 2018-07-18 三菱電機株式会社 通信システム、通信装置、通信方法及び通信プログラム
JP2019016880A (ja) * 2017-07-05 2019-01-31 富士通株式会社 ネットワーク機器、ネットワークシステム及びネットワーク機器設定方法
CN110140325A (zh) * 2017-01-06 2019-08-16 微软技术许可有限责任公司 在成员更改时经由密钥对对话进行部分加密
JP2020126428A (ja) * 2019-02-04 2020-08-20 パナソニックＩｐマネジメント株式会社 通信装置、通信方法およびコンピュータプログラム
JP2020533917A (ja) * 2017-09-15 2020-11-19 テレフオンアクチーボラゲット エルエム エリクソン（パブル） 無線通信システムにおけるセキュリティコンテキスト

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9692757B1 (en) * 2015-05-20 2017-06-27 Amazon Technologies, Inc. Enhanced authentication for secure communications
KR101838511B1 (ko) * 2016-05-17 2018-03-14 현대자동차주식회사 암호화를 적용한 제어기 보안 방법 및 그 장치
US11010485B1 (en) * 2017-03-02 2021-05-18 Apple Inc. Cloud messaging system
EP3709564B1 (en) * 2017-11-06 2023-03-22 Nippon Telegraph And Telephone Corporation Data sharing method, data sharing system, data sharing server, communication terminal, and program
EP3759866A1 (en) * 2018-03-02 2021-01-06 Intertrust Technologies Corporation Trust and identity management systems and methods
US20190305940A1 (en) * 2018-03-28 2019-10-03 Ca, Inc. Group shareable credentials
US10868671B2 (en) * 2018-10-11 2020-12-15 Ademco Inc. Secured communication between host devices
US11218298B2 (en) * 2018-10-11 2022-01-04 Ademco Inc. Secured communication between a host device and a client device
CN110535657B (zh) * 2019-08-21 2022-03-04 上海唯链信息科技有限公司 一种多个私钥管理设备相互身份认证的方法及装置
US10839060B1 (en) * 2019-08-27 2020-11-17 Capital One Services, Llc Techniques for multi-voice speech recognition commands
CN113973001A (zh) * 2020-07-25 2022-01-25 华为技术有限公司 一种认证密钥的更新方法及装置
CN112543098B (zh) * 2020-11-12 2021-10-01 西安交通大学 基于挑战应答机制的智能楼宇移动设备认证系统、方法

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001148715A (ja) * 1999-11-19 2001-05-29 Mitsubishi Electric Corp ネットワークシステム及び端末装置
US6330671B1 (en) * 1997-06-23 2001-12-11 Sun Microsystems, Inc. Method and system for secure distribution of cryptographic keys on multicast networks
JP2010074225A (ja) * 2008-09-16 2010-04-02 Yokogawa Electric Corp ルータ及びネットワークシステム
WO2011163073A1 (en) * 2010-06-22 2011-12-29 Entropic Communications, Inc. Secure node admission in a communication network
JP2012205088A (ja) * 2011-03-25 2012-10-22 Toshiba Corp ノード及びグループ鍵更新方法
JP2013192169A (ja) * 2012-03-15 2013-09-26 Hitachi Ltd 通信装置及びネットワーク認証システム

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6084969A (en) * 1997-12-31 2000-07-04 V-One Corporation Key encryption system and method, pager unit, and pager proxy for a two-way alphanumeric pager network
US9270672B2 (en) * 2011-05-26 2016-02-23 Nokia Technologies Oy Performing a group authentication and key agreement procedure
US20130054964A1 (en) * 2011-08-24 2013-02-28 Motorola Solutions, Inc. Methods and apparatus for source authentication of messages that are secured with a group key
JP5824326B2 (ja) * 2011-10-28 2015-11-25 キヤノン株式会社 管理装置、管理方法、およびプログラム
CN103596173B (zh) * 2013-09-30 2018-04-06 北京智谷睿拓技术服务有限公司 无线网络认证方法、客户端及服务端无线网络认证装置

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6330671B1 (en) * 1997-06-23 2001-12-11 Sun Microsystems, Inc. Method and system for secure distribution of cryptographic keys on multicast networks
JP2001148715A (ja) * 1999-11-19 2001-05-29 Mitsubishi Electric Corp ネットワークシステム及び端末装置
JP2010074225A (ja) * 2008-09-16 2010-04-02 Yokogawa Electric Corp ルータ及びネットワークシステム
WO2011163073A1 (en) * 2010-06-22 2011-12-29 Entropic Communications, Inc. Secure node admission in a communication network
JP2012205088A (ja) * 2011-03-25 2012-10-22 Toshiba Corp ノード及びグループ鍵更新方法
JP2013192169A (ja) * 2012-03-15 2013-09-26 Hitachi Ltd 通信装置及びネットワーク認証システム

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP3297207A4 *

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110140325A (zh) * 2017-01-06 2019-08-16 微软技术许可有限责任公司 在成员更改时经由密钥对对话进行部分加密
JP2019016880A (ja) * 2017-07-05 2019-01-31 富士通株式会社 ネットワーク機器、ネットワークシステム及びネットワーク機器設定方法
JP6359212B1 (ja) * 2017-07-12 2018-07-18 三菱電機株式会社 通信システム、通信装置、通信方法及び通信プログラム
WO2019012617A1 (ja) * 2017-07-12 2019-01-17 三菱電機株式会社 通信システム、通信装置、通信方法及び通信プログラム
JP2020533917A (ja) * 2017-09-15 2020-11-19 テレフオンアクチーボラゲット エルエム エリクソン（パブル） 無線通信システムにおけるセキュリティコンテキスト
US11184812B2 (en) 2017-09-15 2021-11-23 Telefonaktiebolaget Lm Ericsson (Publ) Security context in a wireless communication system
JP7055863B2 (ja) 2017-09-15 2022-04-18 テレフオンアクチーボラゲット エルエム エリクソン（パブル） 無線通信システムにおけるセキュリティコンテキスト
US12137380B2 (en) 2017-09-15 2024-11-05 Telefonaktiebolaget Lm Ericsson (Publ) Security context in a wireless communication system
JP2020126428A (ja) * 2019-02-04 2020-08-20 パナソニックＩｐマネジメント株式会社 通信装置、通信方法およびコンピュータプログラム
JP7170212B2 (ja) 2019-02-04 2022-11-14 パナソニックＩｐマネジメント株式会社 通信装置、通信方法およびコンピュータプログラム

Also Published As

Publication number Publication date
EP3297207A4 (en) 2018-03-21
JPWO2016181586A1 (ja) 2018-02-22
EP3297207A1 (en) 2018-03-21
CN106416122A (zh) 2017-02-15
US20170111357A1 (en) 2017-04-20

Similar Documents

Publication Publication Date Title
JP6254675B2 (ja) 認証方法及び認証システム
JPWO2016181586A1 (ja) 認証方法及び認証システム
CN106415573B (zh) 认证方法、认证系统以及控制器
KR102928823B1 (ko) 차량용 통신 시스템 및 그를 위한 보안 통신 방법
JP7025490B2 (ja) 認証方法およびコントローラ
EP3073668B1 (en) Apparatus and method for authenticating network devices
US20190089546A1 (en) System and method for distribution of identity based key material and certificate
US20170180117A1 (en) One-time pad communications network
US20130054966A1 (en) Systems and methods for providing secure multicast intra-cluster communication
CN106170944A (zh) 用于执行安全通信的系统和方法
CN112352398A (zh) 临时广播密钥协定
WO2017167771A1 (en) Handshake protocols for identity-based key material and certificates
CN101282208B (zh) 安全连接关联主密钥的更新方法和服务器及网络系统
KR20190133972A (ko) IoT 환경에서 기기 인증키를 활용한 메시지 암호키 운용을 위한 단말 기기, 서버, 시스템 및 방법
CN102884756A (zh) 通信装置和通信方法
US20210306308A1 (en) Communication method between mesh network and cloud server, mesh network system and node device thereof
JPWO2019038800A1 (ja) 鍵管理装置および通信機器
JP6805317B2 (ja) 認証方法及び認証システム
CN111556079A (zh) 基于身份加密的可控匿名通信方法
KR20260045863A (ko) 키 정보를 포함하는 페이로드 정보의 전송
CN120528589A (zh) 工作密钥更新方法、通信设备、可读介质、程序产品
CN116846660A (zh) 一种基于国密算法的报文传输方法及装置
HK1232028A1 (en) Method for ensuring system communication safety, safety communication equipment, public key server

Legal Events

Date Code Title Description
ENP Entry into the national phase

Ref document number: 2017517588

Country of ref document: JP

Kind code of ref document: A

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16792321

Country of ref document: EP

Kind code of ref document: A1

REEP Request for entry into the european phase

Ref document number: 2016792321

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2016792321

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE