|
(11) | EP 3 371 930 B1 |
| (12) | EUROPEAN PATENT SPECIFICATION |
|
|
| (54) |
METHOD AND APPARATUS FOR SECURE AGGREGATED EVENT REPORTING VERFAHREN UND VORRICHTUNG ZUR SICHEREN AGGREGIERTEN EREIGNISMELDUNG PROCÉDÉ ET APPAREIL POUR LE RAPPORT SÉCURISÉ D'ÉVÉNEMENTS CUMULÉS |
|
|
|||||||||||||||||||||||||||||||
| Note: Within nine months from the publication of the mention of the grant of the European patent, any person may give notice to the European Patent Office of opposition to the European patent granted. Notice of opposition shall be filed in a written reasoned statement. It shall not be deemed to have been filed until the opposition fee has been paid. (Art. 99(1) European Patent Convention). |
BACKGROUND
Field
[0001] Embodiments of the present invention generally relate to event reporting and more specifically, to a computer implemented method for generating a secure aggregated event report and a system for verifying records in a secure aggregated event report.
Description of the Related Art
[0002] In the utility delivery space, there have been numerous technological advances in efforts to provide improved methods and systems for monitoring and controlling the delivery and use of various utility products (e.g., electricity, water, gas, street lighting, etc.). For example, Smart Grid systems, Advanced Metering Infrastructure (AMI) systems and the like have been developed, which incorporate system devices (e.g. meters) or existing system devices retrofitted with modules that include at least a communication interface, configurable microprocessor, and storage capacity. These devices are configured to communicate using predetermined protocols with other nodes in the network, Wide Area Network (WAN), and/or the Neighborhood Area Network (NAN) access points (e.g., collectors, bridges, mesh gates) in the utility's network.
[0003] A utility network may be employed to monitor utility devices, and perform tasks such as reporting meter readings to head end systems. For example, meters within the AMI system may determine if delivery of power is occurring or if there is a power outage, and may report power readings to a data collection process in the head end system. The ability to achieve this monitoring automatically is an important advancement over the wired, drive-by or house-to-house meter reading methodologies of the past.
[0004] The timely reporting of power outages and restoration across a NAN is critical to maintaining utility access for all customers. Currently, power outage and restoration reports are aggregated before they are sent to a back-end system as described in U.S. Patent No. 8,970,394, titled "Aggregated Real-time Power Outages/Restoration Reporting (RTPOR) in a Secure Mesh Network,". Briefly, power outage or restoration reports are aggregated as they are transmitted through the network to the head end system. Aggregating the reports reduces message volume when there is a large outage event. A complete and accurate set of power event reports is important for the utility to efficiently deploy its resources in order to restore the service. A complete and accurate record is also important for the utility to document its regulatory service level requirements.
[0005] Networks that connect devices to a monitoring process are also being deployed in Distribution Automation (DA) systems for the Smart Grid, in smart cities systems, in Internet of Things systems, and in industrial plant process and control systems. All of these systems have event reports that may need to be secure and scalable when an event is widespread. The types of widespread event that might be reported are power outage and restorations, pipe line pressure events, temperature events, seismic events, gunshot detection events, signal light failures, street light failures, flooding, and the like.
[0006] Secure aggregated event reporting may also be utilized for acknowledging multicast and broadcast message delivery. Typically, broadcast and multicast messages sent to large numbers of devices are not acknowledged by the receiving devices because the quantity of acknowledgements would overwhelm the system. The aggregated event reporting may be used to securely acknowledge receipt of the broadcast and multicast messages.
[0007] However, aggregate event reports have no end-to-end security because each device that the aggregate report passes through must be able to modify the report. As such, the aggregated reports are subject to malicious hackers. The hacked device can falsely report large numbers of power outage events from a plurality of devices. This type of scaled attack is costly to a utility because resources may be deployed to address a large outage where no outage exists.
[0008] The current state-of-the-art for end-to-end security uses either transport layer security such as the Internet Engineering Task Force Transport Layer Security (IETF TLS) or Datagram Transport Layer Security (DTLS) protocols or application sub-layer security which protects the entire application protocol data unit, but cannot protect the individual data records. Therefore, there is a need for a method and apparatus for secure aggregated event reporting.
SUMMARY
[0009] A computer implemented method for generating a secure aggregated event report and a system for verifying records in a secure aggregated event report is provided in claims 1 and 5, respectively.
[0010] These and other features and advantages of the present disclosure may be appreciated from a review of the following detailed description of the present disclosure, along with the accompanying figures in which like reference numerals refer to like parts throughout.
BRIEF DESCRIPTION OF THE DRAWINGS
[0011]
Figure 1 generally depicts a block diagram of an exemplary AMI system for providing secure aggregated event reporting for meters, according to one or more embodiments of the invention;
Figure 2 generally depicts a block diagram of an exemplary device (e.g., meter) for use within a store and forward network such as a network for secure aggregated event reporting, according to one or more embodiments of the invention;
Figure 3 generally depicts an exemplary secure aggregated report, according to one or more embodiments of the invention;
Figure 4 generally depicts a flow diagram of a method for verifying records received in a secure aggregated report, according to one or more embodiments of the invention; and
Figure 5 generally depicts a computer system that can be utilized in various embodiments of the present invention to implement the computer and/or the display, according to one or more embodiments of the invention.
DETAILED DESCRIPTION OF EMBODIMENTS
[0012] Embodiments of the invention provide a system and method for secure aggregated event reporting. As each device (e.g., meter) reports an event, such as a power outage and/or a power restoration, the reporting device adds one or more records to an aggregated event report. In addition to information regarding the event, for example, the start time and end time of an event, duration of the event, an identity of the reporting device, and/or a location of the reporting device, the record also includes cryptographically secured information. When received on the back-end system, the cryptographically secured information can be verified as being received from said reporting device. This verification ensures the integrity of the associated data. In some embodiments, the reporting device may extract a time of a first record (i.e. First Report Time) in the report and append to the time a unique identifier for the device, such as a Media Access Code address. The First Report Time plus Media Access Code address is then protected by a message integrity check (MIC) using, for example a keyed hash function that uses an encryption key that is unique to the reporting device. The hash is appended to the record and the record is then appended to the report.
[0013] When the report is received on the back-end system, each record is validated using the MIC key uniquely associated with the reporting device, such that if the hash generated on the back-end system matches that included in the record, the record is verified as coming from the reporting device. As such, a compromised device can only generate a false record or report for itself, which significantly reduces the scale of a malicious event reporting attack.
[0014] It is effective to use a nonce whenever a key hash function is calculated to preserve the security of the key. Although, a First Report Time in addition to a Media Access Control address may be used for the keyed hash function, any nonce combined with a unique identifier of the device may be used to create the hash that is included in the appended record. For example, the nonce can be a non-repeated random number, or a counter that increments with each use. Other unique identifiers may be device serial numbers and the like.
[0015] Some portions of the detailed description that follow are presented in terms of algorithms or symbolic representations of operations on binary digital signals stored within a memory of a specific apparatus or special purpose computing device or platform. In the context of this particular specification, the term specific apparatus or the like includes a general-purpose computer once it is programmed to perform particular functions pursuant to instructions from program software. Algorithmic descriptions or symbolic representations are examples of techniques used by those of ordinary skill in the signal processing or related arts to convey the substance of their work to others skilled in the art. An algorithm is here, and is generally, considered to be a self-consistent sequence of operations or similar signal processing leading to a desired result. In this context, operations or processing involve physical manipulation of physical quantities. Typically, although not necessarily, such quantities may take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared or otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to such signals as bits, data, values, elements, symbols, characters, terms, numbers, numerals or the like. It should be understood, however, that all of these or similar terms are to be associated with appropriate physical quantities and are merely convenient labels. Unless specifically stated otherwise, as apparent from the following discussion, it is appreciated that throughout this specification discussions utilizing terms such as "processing," "computing," "calculating," "determining" or the like refer to actions or processes of a specific apparatus, such as a special purpose computer or a similar special purpose electronic computing device. In the context of this specification, therefore, a special purpose computer or a similar special purpose electronic computing device is capable of manipulating or transforming signals, typically represented as physical electronic or magnetic quantities within memories, registers, or other information storage devices, transmission devices, or display devices of the special purpose computer or similar special purpose electronic computing device. As used herein, the term device may include a mesh device, a bridged device, a routed device, or any device in a store and forward network. The store and forward network may use a mesh or a tree architecture. Although the present disclosure is described using utility networks, for example those employed in Smart Grid and Advanced Metering Infrastructure (AMI) networks, those skilled in the art will appreciate that the present invention also applies to the broad Internet of Things (loT) space.
[0016] Figure 1 generally depicts a block diagram of an exemplary AMI system 100 for providing secure aggregated event reporting for meters, according to one or more embodiments of the invention. A network A 100 may include a NAN access point (e.g., mesh gate A) 102 and a plurality of meters: meters A 104, B 106, C 108, D 110, E 112, and F 114. Although a mesh network is depicted for network A 100, the network could alternatively be a tree network. A NAN access point may be referred to herein as a mesh gate, NAN-WAN gate, a collector, or a concentrator. In some embodiments, the mesh gate A 102 may communicate with an event application server 118 over a backhaul 116 (e.g., a WAN) and it will be appreciated that any number of mesh gates (e.g., mesh gate B 120 and mesh gate C 124) may communicate with the event application server 118. In some embodiments, the mesh gate A 102 may directly communicate with the event application server 118 via a wired connection. The network A 100 may be any store and forward network where devices receive a message and pass the message on. The network A 100 may be a mesh network, a tree network, or the like. When a device receives the message, the device has the ability to add the device's own status change record to the report. As used herein, the term device may include a mesh device, a routed device a bridged device, or any device in a store and forward network.
[0017] In addition to the mesh gate A 102, the network A 100 may include a plurality of devices (e.g., meters, as shown) or communication hubs, which cover a geographical area. The devices may be in communication with or may otherwise include one or more utility sensors for monitoring utility usage, such as gas, water, or electricity usage and usage patterns at a specific customer location. Alternative devices may include thermostats, user displays, and other components for monitoring utilities, which may be part of a home area network ("HAN"). As discussed in detail below, the mesh gate A 102 may aggregate information from devices (e.g., meters A 104, B 106, C 108, D 110, E 112, and F 114) within the network A 100 and transmit the information to the event application server 118.
[0018] The meters A 104, B 106, C 108, D 110, E 112, and F 114 may be associated with the network A 100 through direct or indirect communications with the mesh gate A 102. Each meter may forward transmissions from other meters within the network A 100 towards the mesh gate A 102. It will be appreciated that while only six meters are depicted in the network A 100, any number of devices may be deployed to cover any number of utility lines or locations, subject to bandwidth constraints with the network A 100 and the mesh gate A 102. Although the devices in the network A 100 are depicted as meters, those skilled in the art will appreciate that the devices may be any type of device capable of reporting an event.
[0019] As depicted, only meters A 104 and D 110 are in direct communications with mesh gate A 102. However, meters B 106, E 112 and F 114 can all reach mesh gate A 102 through meter D 110. Meter D 110 is therefore described as a parent of meters B 106, E112 and F114. Similarly, meter C 108 can reach mesh gate A 102 through meter E 112 and meter D 110. Accordingly, meter A 104 may be described as being 1 "hop" from mesh gate A 102; meter D 110 may be described as being 2 "hops" from mesh gate A, and meter C 108 may be described as being 3 "hops" from mesh gate A.
[0020] It will be appreciated that the backhaul 116 may be any communication medium capable of transmitting digital information. For example, the backhaul 116 may be the Internet, a cellular network, a private network, a phone line configured to carry a dial-up connection, or any other network.
[0021] The event application server 118 may be a computing device configured to receive information, such as status change information, meter readings, or any other data from a plurality of networks and meters. The event application server 118 may also be configured to transmit instructions to the networks, mesh gates, and devices. In certain embodiments, the event application server 118 may be a central processing system including one or more computing systems (i.e., one or more server computers). Where the event application server 118 includes more than one computing system, the computing systems can be connected by one or more networks and the system may be referred to as a head end system. The networks, e.g., networks B 122 and C 126 are similar to network A 100 in operation, as discussed above.
[0022] Figure 2 generally depicts a block diagram 200 of an exemplary device (e.g., meter B 106) for use within a store and forward network such as network A 100 for secure aggregated event reporting, according to one or more embodiments of the invention. A device 200 may include a microcontroller unit (MCU) 202, a communication card 214, an event sensor 216, and a battery, other power or energy storage device or power supply 218. The MCU 202 may include a memory 204, a processor 208, and a transceiver 210. The memory 204 includes an encryption key 206, which is used to produce a keyed hash of a record in an aggregated report, where the record is added by the device 200 as described in further detail below. Generally, the communication card 214 may interface between the MCU 202 and a wired or wireless network. The event sensor 216 performs sensor measurements, which are read by the processor 208. The processor 208 generates a report that is converted by the communication card 214 to signals for transmission over the network. The memory 204 may store instructions and run-time variables for execution. For example, the memory 204 may include both volatile and non-volatile memory. The memory 204 may also store a history of sensor readings from the event sensor 216 and an incoming queue of server instructions. As discussed below, the memory may store status information of the device, and may also store status information received from one or more child devices and one or more encryption keys 206 used for cryptography.
[0023] A device 200 may communicate with an access point and other devices over a network. For example, the device 200 may be an electricity smart meter installed in a residential building or other location to monitor electricity usage. The meter may also control access to energy in response to server instructions, for example, by reducing or stopping the flow of electricity. The device 200 may be a mesh gate.
[0024] In some embodiments, one or more devices 200 may provide an event status change report to a head-end event application server 118 in real-time or near real-time via an access point. As used herein, a "status change" may refer to a loss of power (i.e., a power outage) or a restoration of power (i.e., a power restoration), temperature, pressure drop, pressure surge, pipe failure, sound (e.g., gunshot detection), motion (e.g. seismic activity), signal light outages, street light outages, or flood detection. In the event of an outage, the device may employ a secondary power source that backs up the device's real-time clock, such as a power supply 218, super capacitor or the like, to provide a "last gasp" of activity. For example, a super capacitor may provide the device with approximately 15 seconds of recognition time to determine whether a power outage is momentary or lasting and another approximately 7.5 seconds of time for "last-gasp" radio transmissions.
[0025] In one embodiment, a device 200 first determines that a status change has occurred for a period of time lasting at least as long as a predetermined recognition period. The predetermined recognition period may be any amount of time allowed by the secondary power source, for example, from approximately 5 seconds to approximately 30 seconds, from approximately 10 seconds to approximately 25 seconds, or approximately 15 seconds. Generally, if a device becomes affected by an outage, it may enter a "sleep" mode for the duration of the recognition period, wherein the radio and/or the processor are shut down to preserve the backup power.
[0026] If a status change ends prior to the end of the recognition period, the device may resume normal operation and may record the momentary status change in memory. The recorded status change may then be reported by a device in non-real-time as part of a normal, scheduled reporting process (e.g., daily).
[0027] However, if the status change persists beyond the recognition period, a device may employ an aggregated real-time or near real-time power outage/restoration reporting (RTPOR) algorithm to report the status change to a parent node. Due to the fact that the device may be aware of its location within the network defined by each NAN access point, the aggregated algorithm may be location-based, such that the device may autonomously transmit status change report(s) in a way that increases the probability of the report(s) successfully reaching the NAN access point.
[0028] In one embodiment, each device receiving a status change report or experiencing a status change may prepare and transmit an aggregated status change report to one or more of its parent devices. Each device may prepare and transmit the aggregated status change report to one or more of its parent devices during a reporting period. A reporting period may comprise from approximately 1 second to approximately 5 seconds, for example, or approximately 1.5 seconds. Generally, the reporting period may depend on the secondary source of power employed at each device.
[0029] In one embodiment, a device may prepare a status change report including information regarding a status change. Such information may include, for example, the type of event, the start time and end time of the status change, the duration of the status change, the identity of the device, and/or the location of the device. The details regarding how each device generates a message for the aggregated status change report is described in more detail with respect to Figure 3 below. A report may be prepared during each reporting window, or a single report may be prepared and repeatedly transmitted.
[0030] In one embodiment, the device may receive one or more child status change reports from one or more child devices. During each reporting window, the device may check for such child status reports and, in some embodiments, may include information from such reports in the status change report to be transmitted to the device's parent node. In other words, the device may aggregate status change reports from one or more child devices in the network during one or more reporting windows.
[0031] For example, during each reporting window, each device in a mesh network may check whether it has received new child status change reports and, if so, may transmit an aggregated status change report including this new information. Regardless of whether child status change reports are received or not, devices may continue retransmitting the aggregated status change report at each reporting window, either until adequate power is no longer available for transmission or for a total of the entire reporting period.
[0032] As used herein, the term "child" refers to a device located a further distance away from an access point than the reference device. Similarly, the term "parent" refers to a device located closer to the access point than the reference device. By way of example, if a reference device is located 2 hops from an access point, a device located 1 hop from the access point may be referred to as a "parent device," and a device located 3 hops from the access point may be referred to as a "child device," with respect to the reference device.
[0033] In some embodiments, the device may suspend local generation of all other message transmissions, including but not limited to keep-alive messages and neighbor exchange procedures as used by the NAN network layer protocol, and may suspend the relay of data packets from other nodes in the network.
[0034] Figure 3 generally depicts an exemplary secure aggregated status report 300, according to one or more embodiments of the invention. The aggregated status report 300 includes a plurality of records 302, one from each of Device A - Device E. Although in the present example, the aggregated report 300 includes one record 302 from each reporting device, each reporting device may include a plurality of records 302 in the status report 300. The reporting device that creates the first record includes the first report time 306 in, for example, a report header. Each device thereafter appends a record 302 to the aggregated status report 300. Each record includes information regarding the status change, such as the start time and end time of a status change, a duration of the status change, and/or a location of the reporting device. The record also includes an identity 304 of the reporting device. In the present example, the identity 304 is the IEEE Media Access Control address of the reporting device, although any identifier may be used that identifies the device to the head-end system. The reporting device then signs the record with keyed hash information 308.
[0035] The record information is not limited to the device identity 304 and keyed hash information 308. The record information may also include other information useful to understanding what event has occurred. For example in the case of a power failure, a report could include a field that indicates if an emergency generator was started or in the case of a pipeline failure if a shutoff valve was activated.
[0036] In the present exemplary secure aggregated report 300 the type of event being reported 307 is specified in the application header. However, the report may also be designed to contain different types of events. For example, the report may include power outage events as well as pipe line failure events, in which case an event type field is added to each record. If the report is constructed to only have one event type, the size of the records can be reduced by including a common event type field 307 that applies to all the records in the report.
[0037] In one embodiment, in order to create the hash information 308, the device extracts the first report time 306 from the header, the event type 307 if present, and appends the device's Media Access Code address. The integrity of the first report time, the event type, and the Media Access Code address identifier of the device are then protected using a keyed hash function, such as Cipher-based Message Authentication Code (MAC) using an AES-256 key. If there is additional information in the record, said information is added to the keyed hash calculation in order to protect the integrity of the additional information. Each device has a unique encryption key 206. Although, the time of the first record in addition to a Media Access Code address may be used for a keyed hash, any nonce combined with a unique identifier of the reporting device may be used to create the keyed hash that is included in the record. Although a message integrity check hash and key length is discussed, one skilled in the art will appreciate that any keyed hash function and other key sized appropriate for the security of the system may be utilized. In some embodiments, the AES-256 key used for the message integrity check has been previously established from the reporting device's communication with the back-end system; however any key establishment algorithm may be used, such as pre-configured keys, or a key algorithm such as Elliptic Curve Diffie-Hellman Exchange (ECDHE) key exchange protocol and the like. When the device has no additional records to append to the aggregated report 300, the device transmits the aggregated record to a next device (e.g., a parent device).
[0038] When the report is received on the back-end system, each record is authenticated to ensure it was created on the device specified in the device identity 304. The back-end system maintains a hash key, (i.e., encryption key 206) for each device. The device identity 304 is extracted from the record 302. The hash key associated with the identified device is used to create a hash using an identical process that was used by the reporting device. If the hash generated on the back-end system matches that included in the record, the record integrity is verified as well as identity of the reporting device. If the hashes do not match, the record is determined to be a false record and the record is discarded. Other validated records in the report may be accepted. The head end system may employ a further check to prevent a replay attack that repeats an authentic report. This check looks at the first report time. If this time matches a recent report or is too old to still be in memory, then the report is discarded.
[0039] As such, a malicious attack by a hacker is limited. Each record 302 in the aggregated report 300 is authenticated. In the event a hacker breaks into a meter and generates perhaps thousands of records, false records appearing to be generated by other meters will be discarded, thereby limiting the maliciousness of the attack.
[0040] Figure 4 generally depicts a flow diagram of a method 400 for verifying records received in a secure aggregated report, according to one or more embodiments of the invention. The method 400 starts at step 402 and proceeds to step 404.
[0041] At step 404, a head end system receives a secure aggregated event report. The secure aggregated event report comprises event records from a plurality of devices in a network, as described above.
[0042] At step 406, header information is extracted from the secure aggregated event report. The header information includes at least a First Report Time. In some instances, where the report includes events of a specific type, for example only records that relate to power failure events, or only records that relate to pipe line pressure failure events, the common event type is included in the header.
[0043] At step 408, a device identifier is extracted from a record. The record is retrieved from the report. The record includes a device identifier, a cryptographic hash, as well as other information regarding the event that is being reported. Each device identifier is associated with a unique encryption key. Using the device identifier, the associated encryption key is retrieved from a memory. The memory may be at an event application server, or the memory that contains the encryption keys for the devices may be remote from the event application server, in which case, the encryption key associated with the device identifier is retrieved from the remote memory.
[0044] At step 410, a hash is generated from at least the unique device identifier and the First Report Time. In the case where all records in the aggregated event report are from a plurality of event types, an event type is included in the record. In such case, the event type is also used to generate the hash.
[0045] At step 412, the generated hash is compared to a hash that was generated at the device and stored in the record. If the hashes match, the record is considered to be verified as coming from the device associated with the device identifier in the record and at step 416, the event record is processed and the method 400 proceeds to step 420.
[0046] However, if at step 414, it is determined that the hashes do not match, then the record is determined to be from a hacked device and at step 418, the record is discarded and the method proceeds to step 420.
[0047] At step 420, it is determined whether there are additional records in the secure aggregated event report. If there are additional records, the method 400 proceeds to step 408 and iterates until it is determined at step 420 that no additional records exist in the aggregated event report, at which time the method 400 proceeds to step 422 and ends. As such, malicious attacks are limited because when a record appears to be from a first device but the hashes do not match, it can be determined that the record was created on a second device and is not valid.
[0048] Figure 5 generally depicts a computer system 500 that can be utilized in various embodiments of the present invention to implement the computer and/or the display, according to one or more embodiments.
[0049] Various embodiments of method and apparatus for secure aggregated event reporting, as described herein, may be executed on one or more computer systems, which may interact with various other devices. One such computer system is computer system 500 illustrated by Figure 5, which may in various embodiments implement any of the elements or functionality illustrated in Figures 1-4. In various embodiments, computer system 500 may be configured to implement methods described above. The computer system 500 may be used to implement any other system, device, element, functionality or method of the above-described embodiments. In the illustrated embodiments, computer system 500 may be configured to implement the method 400 as processor-executable executable program instructions 522 (e.g., program instructions executable by processor(s) 510) in various embodiments.
[0050] In the illustrated embodiment, computer system 500 includes one or more processors 510a-510n coupled to a system memory 520 via an input/output (I/O) interface 530. Computer system 500 further includes a network interface 540 coupled to I/O interface 530, and one or more input/output devices 550, such as cursor control device 560, keyboard 570, and display(s) 580. In various embodiments, any of the components may be utilized by the system to receive user input described above. In various embodiments, a user interface may be generated and displayed on display 580. In some cases, it is contemplated that embodiments may be implemented using a single instance of computer system 500, while in other embodiments multiple such systems, or multiple nodes making up computer system 500, may be configured to host different portions or instances of various embodiments. For example, in one embodiment some elements may be implemented via one or more nodes of computer system 500 that are distinct from those nodes implementing other elements. In another example, multiple nodes may implement computer system 500 in a distributed manner.
[0051] In different embodiments, computer system 500 may be any of various types of devices, including, but not limited to, a personal computer system, desktop computer, laptop, notebook, or netbook computer, mainframe computer system, handheld computer, workstation, network computer, a camera, a set top box, a mobile device, a consumer device, video game console, handheld video game device, application server, storage device, a peripheral device such as a switch, modem, router, or in general any type of computing or electronic device.
[0052] In various embodiments, computer system 500 may be a uniprocessor system including one processor 510, or a multiprocessor system including several processors 510 (e.g., two, four, eight, or another suitable number). The network interface 540 functionality may include a load balancer that distributes the event reporting load over the processors 510. The ability to scale the number of processors enables the computer system 500 to handle event reports from large numbers of devices. Processors 510 may be any suitable processor capable of executing instructions. For example, in various embodiments processors 510 may be general-purpose or embedded processors implementing any of a variety of instruction set architectures (ISAs). In multiprocessor systems, each of processors 510 may commonly, but not necessarily, implement the same ISA.
[0053] System memory 520 may be configured to store program instructions 522 and/or data 532 accessible by processor 510. The data stored in 532 may include the reporting device's keys used for the key hash function. In this case is it is advisable to protect this data by encrypting it. In various embodiments, system memory 520 may be implemented using any suitable memory technology, such as static random access memory (SRAM), synchronous dynamic RAM (SDRAM), nonvolatile/Flash-type memory, or any other type of memory. In the illustrated embodiment, program instructions and data implementing any of the elements of the embodiments described above may be stored within system memory 520. In other embodiments, program instructions and/or data may be received, sent or stored upon different types of computer-accessible media or on similar media separate from system memory 520 or computer system 500.
[0054] In one embodiment, I/O interface 530 may be configured to coordinate I/O traffic between processor 510, system memory 520, and any peripheral devices in the device, including network interface 540 or other peripheral interfaces, such as input/output devices 550. In some embodiments, I/O interface 530 may perform any necessary protocol, timing or other data transformations to convert data signals from one component (e.g., system memory 520) into a format suitable for use by another component (e.g., processor 510). In some embodiments, I/O interface 530 may include support for devices attached through various types of peripheral buses, such as a variant of the Peripheral Component Interconnect (PCI) bus standard or the Universal Serial Bus (USB) standard, for example. In some embodiments, the function of I/O interface 530 may be split into two or more separate components, such as a north bridge and a south bridge, for example. Also, in some embodiments some or all of the functionality of I/O interface 530, such as an interface to system memory 520, may be incorporated directly into processor 510.
[0055] Network interface 540 may be configured to allow data to be exchanged between computer system 500 and other devices attached to a network (e.g., network 590), such as one or more external systems or between nodes of computer system 500. In various embodiments, network 590 may include one or more networks including but not limited to Local Area Networks (LANs) (e.g., an Ethernet or corporate network), Wide Area Networks (WANs) (e.g., the Internet), wireless data networks, some other electronic data network, or some combination thereof. In various embodiments, network interface 540 may support communication via wired or wireless general data networks, such as any suitable type of Ethernet network, for example; via telecommunications/telephony networks such as analog voice networks or digital fiber communications networks; via storage area networks such as Fiber Channel SANs, or via any other suitable type of network and/or protocol.
[0056] Input/output devices 550 may, in some embodiments, include one or more display terminals, keyboards, keypads, touchpads, scanning devices, voice or optical recognition devices, or any other devices suitable for entering or accessing data by one or more computer systems 500. Multiple input/output devices 550 may be present in computer system 500 or may be distributed on various nodes of computer system 500. In some embodiments, similar input/output devices may be separate from computer system 500 and may interact with one or more nodes of computer system 500 through a wired or wireless connection, such as over network interface 540.
[0057] Those skilled in the art will appreciate that computer system 500 is merely illustrative and is not intended to limit the scope of embodiments. In particular, the computer system and devices may include any combination of hardware or software that can perform the indicated functions of various embodiments, including computers, network devices, Internet appliances, PDAs, wireless phones, pagers, and the like. Computer system 500 may also be connected to other devices that are not illustrated, or instead may operate as a stand-alone system. In addition, the functionality provided by the illustrated components may in some embodiments be combined in fewer components or distributed in additional components. Similarly, in some embodiments, the functionality of some of the illustrated components may not be provided and/or other additional functionality may be available.
[0058] Those skilled in the art will also appreciate that, while various items are illustrated as being stored in memory or on storage while being used, these items or portions of them may be transferred between memory and other storage devices for purposes of memory management and data integrity. Alternatively, in other embodiments some or all of the software components may execute in memory on another device and communicate with the illustrated computer system via inter-computer communication. Some or all of the system components or data structures may also be stored (e.g., as instructions or structured data) on a computer-accessible medium or a portable article to be read by an appropriate drive, various examples of which are described above. In some embodiments, instructions stored on a computer-accessible medium separate from computer system 500 may be transmitted to computer system 500 via transmission media or signals such as electrical, electromagnetic, or digital signals, conveyed via a communication medium such as a network and/or a wireless link. Various embodiments may further include receiving, sending or storing instructions and/or data implemented in accordance with the foregoing description upon a computer-accessible medium or via a communication medium. In general, a computer-accessible medium may include a storage medium or memory medium such as magnetic or optical media, e.g., disk or DVD/CD-ROM, volatile or non-volatile media such as RAM (e.g., SDRAM, DDR, RDRAM, SRAM, and the like), ROM, and the like.
[0059] The embodiments of the present invention may be embodied as methods, apparatus, electronic devices, and/or computer program products. Accordingly, the embodiments of the present invention may be embodied in hardware and/or in software (including firmware, resident software, micro-code, etc.), which may be generally referred to herein as a "circuit" or "module". Furthermore, the present invention may take the form of a computer program product on a computer-usable or computer-readable storage medium having computer-usable or computer-readable program code embodied in the medium for use by or in connection with an instruction execution system. In the context of this document, a computer-usable or computer-readable medium may be any medium that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device. These computer program instructions may also be stored in a computer-usable or computer-readable memory that may direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer usable or computer-readable memory produce an article of manufacture including instructions that implement the function specified in the flowchart and/or block diagram block or blocks.
[0060] The computer-usable or computer-readable medium may be, for example but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, device, or propagation medium. More specific examples (a non-exhaustive list) of the computer-readable medium include the following: hard disks, optical storage devices, a transmission media such as those supporting the Internet or an intranet, magnetic storage devices, an electrical connection having one or more wires, a portable computer diskette, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, and a compact disc read-only memory (CD-ROM).
[0061] Computer program code for carrying out operations of the present invention may be written in an object oriented programming language, such as Java.RTM, Smalltalk or C++, and the like. However, the computer program code for carrying out operations of the present invention may also be written in conventional procedural programming languages, such as the "C" programming language and/or any other lower level assembler languages. It will be further appreciated that the functionality of any or all of the program modules may also be implemented using discrete hardware components, one or more Application Specific Integrated Circuits (ASICs), or programmed Digital Signal Processors or microcontrollers.
determining, by a device (200) of a plurality of devices (104, 106, 108, 110, 112, 114), that a status change has occurred at the device (200), wherein the status change is one of a loss of power or a restoration of power, temperature, pressure drop, pressure surge, pipe failure, sound, motion, signal light outages, street light outages, or flood detection;
receiving, by the device (200), a status change report from one or more child devices, wherein each of the one or more child devices is located a further distance away from an access point than the device (200), and wherein the one or more child devices send messages to the access point through the device (200);
generating, by the device (200), a device status change record, wherein the status change record comprises an event type, unique device identifier, and one or more time fields for a start time of the status change, an end time of the status change, or a duration of the status change;
generating, by the device (200), a record verification field, comprising:
combining a nonce, wherein the nonce is one or more time fields for a start time of the status change, an end time of the status change, or a duration of the status change, an event type, and a unique device identifier;
generating a message integrity check code for the combined nonce, event type and device identifier, wherein generating the message integrity check comprises performing a keyed hash function on the combined nonce, the event type, and device identifier using a pre-defined encryption key (206) associated with the device (200); and
appending the message integrity check code to the device status change record;
appending, by the device (200), the device status change record to the received status change report; and
transmitting, by the device (200), the status change report to one or more parent devices toward a head end system;
receiving, by the head end system, the status change report, wherein the status change report comprises at least one status change record from a device (200) in a plurality of devices (104, 106, 108, 110, 112, 114) in a network;
retrieving, by the head end system, the device identifier, the event type, and the message integrity check code from the at least one record;
retrieving, by the head end system, an encryption key (206) associated with the device identifier;
performing, by the head end system, a keyed hash function on a combination of the nonce, the event type, and the unique device identifier using the encryption key (206) associated with the device identifier;
comparing, by the head end system, a result of the keyed hash function to the message integrity check code retrieved from the at least one record;
determining, by the head end system, the record is from the device (200) associated with the device identifier when the result of the keyed hash function matches the message integrity check code retrieved from the at least one record; and
discarding, by the head end system, the record when the result of the keyed hash function does not match the message integrity check code retrieved from the at least one record.
a plurality of devices, wherein each device comprises:
a) at least one processor;
b) at least one input device; and
c) at least one storage device storing processor-executable instructions which, when executed by the at least one processor, perform a method including:
determining, by a device, that a status change has occurred at the device, wherein the status change is one of a loss of power or a restoration of power, temperature, pressure drop, pressure surge, pipe failure, sound, motion, signal light outages, street light outages, or flood detection;
receiving, by the device, a status change report from one or more child devices, wherein each of the one or more child devices is one or more hops from the device, and wherein the one or more child devices send messages to an access point through the device;
generating, by the device, a device status change record, wherein the status change record comprises an event type, unique device identifier, and a nonce, wherein the nonce is one or more time fields for a start time of the status change, an end time of the status change, or a duration of the status change;
generating a record verification field, comprising:
combining the nonce, the event type, and the unique device identifier;
generating a message integrity check code for the combined nonce, event type and device identifier, wherein generating the message integrity check comprises performing a keyed hash function on the combined nonce, the event type, and device identifier using a pre-defined encryption key associated with the device; and
appending the message integrity check code to the device status change record;
appending the device status change record to the received status change report; and
transmitting, by the device, the status change report to one or more parent devices toward a head end system; and
a server comprising:
a) at least one processor;
b) at least one input device; and
c) at least one storage device storing processor-executable instructions which, when executed by the at least one processor, perform a method including:
receiving the status change report, wherein the status change report comprises at least one status change record from a device in a plurality of devices in a network;
retrieving the device identifier, the event type, and the message integrity check code from the at least one record;
retrieving an encryption key associated with the device identifier;
performing a keyed hash function on a combination of the nonce, the event type, and the unique device identifier using the encryption key associated with the device identifier;
comparing a result of the keyed hash function to the message integrity check code retrieved from the at least one record;
determining the record is from the device associated with the device identifier when the result of the keyed hash function matches the message integrity check code retrieved from the at least one record; and
discarding the record when the result of the keyed hash function does not match the message integrity check code retrieved from the at least one record.
Bestimmen durch eine Vorrichtung (200) mehrerer Vorrichtungen (104, 106, 108, 110, 112, 114), dass eine Statusänderung an der Vorrichtung (200) stattgefunden hat, wobei die Statusänderung entweder ein Verlust der Leistung oder eine Wiederherstellung der Leistung, eine Temperatur, ein Druckabfall, ein Druckstoß, ein Rohrausfall, ein Ton, eine Bewegung, Signallicht-Ausfälle, Straßenleuchten-Ausfälle oder eine Überflutungsdetektion ist;
Empfangen durch die Vorrichtung (200) eines Statusänderungsberichts von einer oder mehreren Nachfolgervorrichtungen, wobei sich jede der einen oder der mehreren Nachfolgervorrichtungen in einer weiteren Entfernung entfernt von einem Zugangspunkt als die Vorrichtung (200) befindet und wobei die eine oder die mehreren Nachfolgervorrichtungen Nachrichten durch die Vorrichtung (200) an den Zugangspunkt senden;
Erzeugen durch die Vorrichtung (200) eines Vorrichtungs-Zustandsänderungsdatensatzes, wobei der Zustandsänderungsdatensatz einen Ereignistyp, eine eindeutige Vorrichtungskennung und ein oder mehrere Zeitfelder für einen Anfangszeitpunkt der Zustandsänderung, einen Endzeitpunkt der Zustandsänderung oder eine Dauer der Zustandsänderung umfasst;
Erzeugen durch die Vorrichtung (200) eines Datensatzverifikationsfeldes, das Folgendes umfasst:
Kombinieren einer Nonce, wobei die Nonce ein oder mehrere Zeitfelder für einen Anfangszeitpunkt der Statusänderung, einen Endzeitpunkt der Statusänderung oder eine Dauer der Statusänderung ist, eines Ereignistyps und einer eindeutigen Vorrichtungskennung;
Erzeugen eines Nachrichtenintegritäts-Prüfcodes für die Kombination von Nonce, Ereignistyp und Vorrichtungskennung, wobei das Erzeugen der Nachrichtenintegritätsprüfung das Ausführen einer verschlüsselten Hash-Funktion an der Kombination von Nonce, Ereignistyp und Vorrichtungskennung unter Verwendung eines vorgegebenen Verschlüsselungsschlüssels (206), der der Vorrichtung (200) zugeordnet ist, umfasst; und
Anfügen des Nachrichtenintegritäts-Prüfcodes an den Vorrichtungs-Statusänderungsdatensatz;
Anfügen durch die Vorrichtung (200) des Vorrichtungs-Statusänderungsdatensatzes an den empfangenen Statusänderungsbericht; und
Übertragen durch die Vorrichtung (200) des Statusänderungsberichts zu einer oder mehreren Vorgängervorrichtungen in Richtung eines Kopfendesystems;
Empfangen durch das Kopfendesystem des Statusänderungsberichts, wobei der Statusänderungsbericht wenigstens einen Statusänderungsdatensatz von einer Vorrichtung (200) in mehreren Vorrichtungen (104, 106, 108, 110, 112, 114) in einem Netz umfasst;
Wiedergewinnen durch das Kopfendesystem der Vorrichtungskennung, des Ereignistyps und des Nachrichtenintegritäts-Prüfcodes aus dem wenigstens einen Datensatz;
Wiedergewinnen durch das Kopfendesystem eines Verschlüsselungsschlüssels (206), der der Vorrichtungskennung zugeordnet ist;
Ausführen durch das Kopfendesystem einer verschlüsselten Hash-Funktion an einer Kombination aus der Nonce, dem Ereignistyp und der eindeutigen Vorrichtungskennung unter Verwendung des Verschlüsselungsschlüssels (206), der der Vorrichtungskennung zugeordnet ist;
Vergleichen durch das Kopfendesystem eines Ergebnisses der verschlüsselten Hash-Funktion mit dem aus dem wenigstens einen Datensatz wiedergewonnen Nachrichtenintegritäts-Prüfcode;
Bestimmen durch das Kopfendesystem, dass der Datensatz von der Vorrichtung (200), der die Vorrichtungskennung zugeordnet ist, ist, wenn das Ergebnis der verschlüsselten Hash-Funktion mit dem aus dem wenigstens einen Datensatz wiedergewonnenen Nachrichtenintegritäts-Prüfcode übereinstimmt; und
Verwerfen durch das Kopfendesystem des Datensatzes, wenn das Ergebnis der verschlüsselten Hash-Funktion nicht mit dem aus dem wenigstens einen Datensatz wiedergewonnenen Nachrichtenintegritäts-Prüfcode übereinstimmt.
mehrere Vorrichtungen, wobei jede Vorrichtung Folgendes umfasst:
a) wenigstens einen Prozessor;
b) wenigstens eine Eingabevorrichtung; und
c) wenigstens eine Speichervorrichtung, die prozessorausführbare Anweisungen speichert, die, wenn sie durch den wenigstens einen Prozessor ausgeführt werden, ein Verfahren ausführen, das Folgendes enthält:
Bestimmen durch eine Vorrichtung, dass eine Statusänderung an der Vorrichtung stattgefunden hat, wobei die Statusänderung entweder ein Verlust der Leistung oder eine Wiederherstellung der Leistung, eine Temperatur, ein Druckabfall, ein Druckstoß, ein Rohrausfall, ein Ton, eine Bewegung, Signallicht-Ausfälle, Straßenleuchten-Ausfälle oder eine Überflutungsdetektion ist;
Empfangen durch die Vorrichtung eines Statusänderungsberichts von einer oder mehreren Nachfolgervorrichtungen, wobei sich jede der einen oder der mehreren Nachfolgervorrichtungen ein oder mehrere Sprünge von der Vorrichtung befindet und wobei die eine oder die mehreren Nachfolgervorrichtungen Nachrichten durch die Vorrichtung an einen Zugangspunkt senden;
Erzeugen durch die Vorrichtung eines Vorrichtungs-Zustandsänderungsdatensatzes, wobei der Zustandsänderungsdatensatz einen Ereignistyp, eine eindeutige Vorrichtungskennung und eine Nonce umfasst, wobei die Nonce ein oder mehrere Zeitfelder für einen Anfangszeitpunkt der Zustandsänderung, einen Endzeitpunkt der Zustandsänderung oder eine Dauer der Zustandsänderung ist;
Erzeugen eines Datensatzverifikationsfeldes, das Folgendes umfasst:
Kombinieren der Nonce, des Ereignistyps und der eindeutigen Vorrichtungs kennung;
Erzeugen eines Nachrichtenintegritäts-Prüfcodes für die Kombination von Nonce, Ereignistyp und Vorrichtungskennung, wobei das Erzeugen der Nachrichtenintegritätsprüfung das Ausführen einer verschlüsselten Hash-Funktion an der Kombination von Nonce, Ereignistyp und Vorrichtungskennung unter Verwendung eines vorgegebenen Verschlüsselungsschlüssels, der der Vorrichtung zugeordnet ist, umfasst; und
Anfügen des Nachrichtenintegritäts-Prüfcodes an den Vorrichtungs-Statusänderungsdatensatz;
Anfügen des Vorrichtungs-Statusänderungsdatensatzes an den empfangenen Statusänderungsbericht; und
Übertragen durch die Vorrichtung des Statusänderungsberichts zu einer oder mehreren Vorgängervorrichtungen in Richtung eines Kopfendesystems; und
einen Server, der Folgendes umfasst:
a) wenigstens einen Prozessor;
b) wenigstens eine Eingabevorrichtung und
c) wenigstens eine Speichervorrichtung, die prozessorausführbare Anweisungen speichert, die, wenn sie durch den wenigstens einen Prozessor ausgeführt werden, ein Verfahren ausführen, das Folgendes enthält:
Empfangen des Statusänderungsberichts, wobei der Statusänderungsbericht wenigstens einen Statusänderungsdatensatz von einer Vorrichtung in mehreren Vorrichtungen in einem Netz umfasst;
Wiedergewinnen der Vorrichtungskennung, des Ereignistyps und des Nachrichtenintegritäts-Prüfcodes aus dem wenigstens einen Datensatz;
Wiedergewinnen eines Verschlüsselungsschlüssels, der der Vorrichtungskennung zugeordnet ist;
Ausführen einer verschlüsselten Hash-Funktion an einer Kombination aus Nonce, Ereignistyp und eindeutiger Vorrichtungskennung unter Verwendung des Verschlüsselungsschlüssels, der der Vorrichtungskennung zugeordnet ist;
Vergleichen eines Ergebnisses der verschlüsselten Hash-Funktion mit dem aus dem wenigstens einen Datensatz wiedergewonnen Nachrichtenintegritäts-Prüfcode;
Bestimmen, dass der Datensatz von der Vorrichtung, der die Vorrichtungskennung zugeordnet ist, ist, wenn das Ergebnis der verschlüsselten Hash-Funktion mit dem aus dem wenigstens einen Datensatz wiedergewonnenen Nachrichtenintegritäts-Prüfcode übereinstimmt; und
Verwerfen des Datensatzes, wenn das Ergebnis der verschlüsselten Hash-Funktion nicht mit dem aus dem wenigstens einen Datensatz wiedergewonnenen Nachrichtenintegritäts-Prüfcode übereinstimmt.
la détermination, par un dispositif (200) d'une pluralité de dispositifs (104, 106, 108, 110, 112, 114), qu'un changement d'état s'est produit au niveau du dispositif (200), le changement d'état étant une perte de puissance ou un rétablissement de puissance, une température, une chute de pression, une surpression, une défaillance de conduit, un son, un mouvement, des coupures de feux de signalisation, des coupures d'éclairage public, ou une détection d'inondation ;
la réception, par le dispositif (200), d'un rapport de changement d'état à partir d'un ou plusieurs dispositifs enfants, chacun des dispositifs enfants étant situé à une distance plus éloignée d'un point d'accès que le dispositif (200), et dans lequel les un ou plusieurs dispositifs enfants envoient des messages au point d'accès par le biais du dispositif (200) ;
la génération, par le dispositif (200), d'un enregistrement de changement d'état de dispositif, l'enregistrement de changement d'état comprenant un type d'événement, un identifiant de dispositif unique et un ou plusieurs champs temporels d'une heure de début du changement d'état, d'une heure de fin du changement d'état ou d'une durée du changement d'état ;
la génération, par le dispositif (200), d'un champ de vérification d'enregistrement, comprenant :
la combinaison d'un nonce, le nonce étant un ou plusieurs champs temporels d'une heure de début du changement d'état, d'une heure de fin du changement d'état ou d'une durée du changement d'état, un type d'événement et un identifiant de dispositif unique ;
la génération d'un code de vérification d'intégrité de message pour le nonce combiné, le type d'événement et l'identifiant de dispositif, dans lequel la génération de la vérification d'intégrité de message comprend la réalisation d'une fonction de hachage à clé sur le nonce combiné, le type d'événement et l'identifiant de dispositif à l'aide d'une clé de cryptage prédéfinie (206) associée au dispositif (200) ; et
l'ajout du code de vérification d'intégrité de message à l'enregistrement de changement d'état du dispositif ;
l'ajout, par le dispositif (200), de l'enregistrement de changement d'état de dispositif au rapport de changement d'état reçu ; et
la transmission, par le dispositif (200), du rapport de changement d'état à un ou plusieurs dispositifs parents vers un système de tête ;
la réception, par le système de tête, du rapport de changement d'état, le rapport de changement d'état comprenant au moins un enregistrement de changement d'état d'un dispositif (200) dans une pluralité de dispositifs (104, 106, 108, 110, 112, 114) dans un réseau ;
la récupération, par le système de tête, de l'identifiant de dispositif, du type d'événement et du code de vérification d'intégrité de message à partir de l'au moins un enregistrement ;
la récupération, par le système de tête, d'une clé de cryptage (206) associée à l'identifiant du dispositif ;
la réalisation, par le système de tête, d'une fonction de hachage à clé sur une combinaison du nonce, du type d'événement et de l'identifiant de dispositif unique à l'aide de la clé de cryptage (206) associée à l'identifiant du dispositif ;
la comparaison, par le système de tête, d'un résultat de la fonction de hachage à clé au code de vérification d'intégrité de message récupéré à partir de l'au moins un enregistrement ;
la détermination, par le système de tête, que l'enregistrement provient du dispositif (200) associé à l'identifiant de dispositif lorsque le résultat de la fonction de hachage à clé correspond au code de vérification d'intégrité de message récupéré à partir de l'au moins un enregistrement ; et
le rejet, par le système de tête, de l'enregistrement lorsque le résultat de la fonction de hachage à clé ne correspond pas au code de vérification d'intégrité de message récupéré à partir de l'au moins un enregistrement.
une pluralité de dispositifs, chaque dispositif comprenant :
a) au moins un processeur ;
b) au moins un dispositif d'entrée ; et
c) au moins un dispositif de mémorisation mémorisant des instructions exécutables par processeur qui, à leur exécution par l'au moins un processeur, réalisent un procédé comprenant :
la détermination, par un dispositif qu'un changement d'état s'est produit au niveau du dispositif, le changement d'état étant une perte de puissance ou un rétablissement de puissance, une température, une chute de pression, une surpression, une défaillance de conduit, un son, un mouvement, des coupures de feux de signalisation, des coupures d'éclairage public, ou une détection d'inondation ;
la réception, par le dispositif, d'un rapport de changement d'état à partir d'un ou plusieurs dispositifs enfants, chacun des dispositifs enfants étant situé à un ou plusieurs sauts du dispositif, et les un ou plusieurs dispositifs enfants envoyant des messages à un point d'accès par le biais du dispositif ;
la génération, par le dispositif, d'un enregistrement de changement d'état de dispositif, l'enregistrement de changement d'état comprenant un type d'événement, un identifiant de dispositif unique et un ou plusieurs champs temporels d'une heure de début du changement d'état, d'une heure de fin du changement d'état ou d'une durée du changement d'état ;
la génération d'un champ de vérification d'enregistrement, comprenant :
la combinaison d'un nonce, du type d'événement et de l'identifiant de dispositif unique ;
la génération d'un code de vérification d'intégrité de message pour les nonce, type d'événement et identifiant de dispositif combinés, dans lequel la génération de la vérification d'intégrité de message comprend la réalisation d'une fonction de hachage à clé sur le nonce combiné, le type d'événement et l'identifiant de dispositif à l'aide d'une clé de cryptage prédéfinie associée au dispositif ; et
l'ajout du code de vérification d'intégrité de message à l'enregistrement de changement d'état de dispositif ;
l'ajout de l'enregistrement de changement d'état de dispositif au rapport de changement d'état reçu ; et
la transmission, par le dispositif, du rapport de changement d'état à un ou plusieurs dispositifs parents vers un système de tête ; et
un serveur comprenant :
a) au moins un processeur ;
b) au moins un dispositif d'entrée ; et
c) au moins un dispositif de mémorisation mémorisant des instructions exécutables par processeur qui, à leur exécution par l'au moins un processeur, réalisent un procédé comportant :
la réception du rapport de changement d'état, le rapport de changement d'état comprenant au moins un enregistrement de changement d'état d'un dispositif dans une pluralité de dispositifs dans un réseau ;
la récupération de l'identifiant de dispositif, du type d'événement et du code de vérification d'intégrité de message à partir de l'au moins un enregistrement ;
la récupération d'une clé de cryptage associée à l'identifiant du dispositif ;
la réalisation d'une fonction de hachage à clé sur une combinaison du nonce, du type d'événement et de l'identifiant unique de dispositif à l'aide de la clé de cryptage associée à l'identifiant de dispositif ;
la comparaison d'un résultat de la fonction de hachage à clé au code de vérification d'intégrité de message récupéré à partir de l'au moins un enregistrement ;
la détermination que l'enregistrement provient du dispositif associé à l'identifiant de dispositif lorsque le résultat de la fonction de hachage à clé correspond au code de vérification d'intégrité de message récupéré à partir de l'au moins un enregistrement ; et
le rejet de l'enregistrement lorsque le résultat de la fonction de hachage à clé ne correspond pas au code de vérification d'intégrité de message récupéré à partir de l'au moins un enregistrement.
REFERENCES CITED IN THE DESCRIPTION
This list of references cited by the applicant is for the reader's convenience only. It does not form part of the European patent document. Even though great care has been taken in compiling the references, errors or omissions cannot be excluded and the EPO disclaims all liability in this regard.
Patent documents cited in the description