US20120047557A1 - Method and System for Device Integrity Authentication - Google Patents
Method and System for Device Integrity Authentication Download PDFInfo
- Publication number
- US20120047557A1 US20120047557A1 US12/947,662 US94766210A US2012047557A1 US 20120047557 A1 US20120047557 A1 US 20120047557A1 US 94766210 A US94766210 A US 94766210A US 2012047557 A1 US2012047557 A1 US 2012047557A1
- Authority
- US
- United States
- Prior art keywords
- trust
- integrity value
- level
- integrity
- processing module
- 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.)
- Abandoned
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
-
- 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/12—Applying verification of the received information
- H04L63/126—Applying verification of the received information the source of the received data
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y04—INFORMATION OR COMMUNICATION TECHNOLOGIES HAVING AN IMPACT ON OTHER TECHNOLOGY AREAS
- Y04S—SYSTEMS INTEGRATING TECHNOLOGIES RELATED TO POWER NETWORK OPERATION, COMMUNICATION OR INFORMATION TECHNOLOGIES FOR IMPROVING THE ELECTRICAL POWER GENERATION, TRANSMISSION, DISTRIBUTION, MANAGEMENT OR USAGE, i.e. SMART GRIDS
- Y04S40/00—Systems for electrical power generation, transmission, distribution or end-user application management characterised by the use of communication or information technologies, or communication or information technology specific aspects supporting them
- Y04S40/20—Information technology specific aspects, e.g. CAD, simulation, modelling, system security
Definitions
- This invention relates in general to networked devices and more particularly to a method and system for device integrity authentication.
- Efforts have increased to modernize the nation's aging electrical grid in order to be ready for next generation usage. This modernization has brought digitization to the electric grid with many industrial control components being networked and remotely controlled. However, the details of how these components interconnect and communicate have remained proprietary. With the modernization, more and more devices are added to the network and implemented with open standards and technology.
- An example of a component being networked is a smart meter deployed at a customer premises that provides meter readings of electrical usage. The deployment of these smart meters is with limited protection or adequate security measures.
- Some smart meters may be equipped with temper detection mechanisms that can detect when the meter is opened or moved and shutdown or send an alert signal in response thereto.
- smart meters send critical data from one meter to another. If one meter in the network is compromised, this critical data can be used to adversely affect system operation for illicit gain.
- Current smart meters have no capability to detect an attack remotely, by insiders, or zero-day attacks that may affect the software executing in the smart meter.
- a method for device integrity authentication includes receiving, at a second device, a measured integrity value from a first device.
- the measured integrity value of the first device is compared at the second device to an embedded integrity value associated with the second device.
- a level of trust for the first device is determined by the second device based on the comparison.
- Application of a policy to the first device is facilitated by the second device based on the comparison.
- Certain embodiments of the invention may provide one or more technical advantages.
- An example of a technical advantage of one embodiment is to have a second device perform an integrity check on a first device.
- Another technical advantage is to apply a policy to the first device based on the results of the integrity authentication.
- FIG. 1 illustrates an example embodiment of a system with networked devices
- FIG. 2 illustrates an example embodiment of a device in the network
- FIG. 3 illustrates an example embodiment of a method for performing an integrity check within the device
- FIG. 4 illustrates an example embodiment of a method for computing a measured integrity value of the device
- FIG. 5 illustrates an example embodiment of a system with two devices and a backend server
- FIG. 6 illustrates an example embodiment of a method to allow a second device to determine a level of trust for a first device
- FIG. 7 illustrates an example embodiment of a method involved in transmitting data from the first device to the second device
- FIG. 8 illustrates an example embodiment of a method involved in receiving data at the second device from the first device.
- FIG. 1 illustrates an embodiment of a system 100 operable to facilitate the application of a policy to one or more devices 105 .
- the system 100 includes a network comprising devices 105 , gateways 110 , and a backend server 115 .
- Devices 105 may be operable to communicate with one another and to the gateways 110 .
- Devices 105 may communicate directly with the backend server 115 or through a gateway 110 .
- a device 105 may take certain actions in accordance with a policy.
- Device 105 may store the policy within local storage, or, alternatively, an outside source may communicate the policy to device 105 .
- the policy may come from other devices 105 , from backend server 115 via gateway 110 and/or other devices 105 , or from backend server 115 directly.
- Devices 105 , gateways 110 , and backend server 115 may be coupled to any suitable communication network.
- a communication network may comprise all or a portion of one or more of the following: a public switched telephone network (PSTN), a public or private data network, a local area network (LAN), a metropolitan area network (MAN), a wide area network (WAN), a local, regional, or global communication or computer network such as the Internet, a wireline or wireless network, an enterprise intranet, other suitable communication link, or any combination of any of the preceding.
- PSTN public switched telephone network
- LAN local area network
- MAN metropolitan area network
- WAN wide area network
- gateways 110 may be connected by fiber backbone to backend server 115 .
- devices 105 may comprise radio transmitters operable to transmit data from a device 105 wirelessly to other devices 105 , gateways 110 , and backend server 115 .
- devices 105 may operate as smart meters operable to measure electricity usage for customers of an electric utility.
- devices 105 act as smart meters, they may form a mesh network in which management data, control data, and meter data are transmitted from device to device with each device serving as a relay node.
- backend server 115 may be located at an electric utility company.
- Meter data may comprise information about the electric usage at a particular customer's premises.
- Control data may comprise data associated with controlling particular components on one or more devices 105 .
- Management data may comprise data associated with forming and maintaining the network. For example, management data could indicate the route that data from a particular device 105 would take in order to reach backend server 115 .
- a policy may be associated with these different types of data.
- devices 105 may be any of a range of devices.
- the devices 105 could comprise several of the other components of a smart electricity grid. More broadly speaking, the devices 105 may comprise one or more components of any supervisory control and data acquisition (SCADA) or industrial control system.
- SCADA supervisory control and data acquisition
- the devices 105 may be any device deployed on a home area network (HAN).
- HAN home area network
- devices 105 may be employed in a comparatively small network such as a HAN or deployed as a large scale network, such as an electric grid deployed over a neighborhood or city.
- FIG. 2 illustrates an embodiment of a device 105 operable to facilitate application of a policy.
- device 105 may include a control processing module 205 , which may have general control over the operations and features of device 105 .
- Control processing module 205 may be coupled to several processing modules operable to perform different functions of device 105 such as integrity check processing module 210 , communication processing module 215 , measuring processing module 220 , and other general processing modules 225 . These processing modules may perform various functions.
- control processing module 205 also may be coupled to a policy repository 230 , a general storage 235 , and/or a device identifier register 245 .
- Policy repository 230 may contain policies to be applied to device 105 under certain conditions.
- General storage 235 may comprise a storage unit generally accessible by control processing module 205 and the other processing modules included on device 105 .
- Device identifier register 245 may be configurable to contain the value of an identifier of device 105 .
- Communication processing module 215 , measuring processing module 220 , and general processing modules 225 may perform a wide range of functions.
- communication processing module 215 may operate to transmit or receive communications from other devices 105 , gateways 110 , backend server 115 , or any other external source. It also may operate to assist in determining the route a certain communication will take to get to a specific destination. For example, it may determine which other devices 105 to communicate with in order for a transmission of data to get to a particular other device 105 , a particular gateway 110 , or backend server 115 .
- measuring processing module 220 may measure electricity usage for an electricity user's premises.
- General processing modules 225 may perform any of a number functions such as measuring ambient environment factors proximate to device 105 , testing of various elements of device 105 , and maintaining an appropriate temperature for device 105 .
- Communication processing module 215 , measuring processing module 220 , and general processing modules 225 may operate under the direction of control processing module 205 according to a policy stored in policy repository 230 .
- an identifier of device 105 may be used to determine what policy should apply to device 105 as described in more detail below.
- an identifier may comprise a Media Access Control (MAC) address or an (Internet Protocol) IP address.
- the identifier may be hardwired or hardcoded into device identifier register 245 at run-time, or alternatively may be updatable after deployment of device 105 .
- An identifier may be unique in the sense that it uniquely identifies a particular device 105 in a plurality of devices 105 .
- the identifier contained within device identifier register 245 of a particular device 105 may be the same as an identifier for one or more other devices 105 .
- device 105 may include none, one, two, or more device identifier registers 245 . They may be configured to contain any combination of the types of identifiers discussed herein.
- device identifier register 245 may be in a protected section of device 105 , such that device identifier register 245 is more difficult to modify once device 105 is deployed in the field.
- the protected section of device 105 could be configured in hardware, software, or firmware.
- device identifier register 245 may be a part of read-only memory or computed from a program configured to be non-modifiable.
- An embedded integrity value register 240 may store a value which can be accessed by integrity check processing module 210 when performing its integrity check, as further described below.
- the value stored in embedded integrity value register 240 may be programmed at the time of the manufacture of device 105 . Alternatively, it may be programmed at some later time.
- Embedded integrity value register 240 may be a part of a protected section of the device 105 in a similar fashion as that described above for device identifier register 245 .
- device 105 may employ multiple embedded integrity value registers 240 .
- the embedded integrity value registers may employ various formats, such as hardware, firmware, or software. This approach may allow redundancy in the integrity checking feature of integrity check processing module 210 as further described below.
- integrity check processing module 210 may be operable to perform an integrity check by determining a measured integrity value of the device 105 and comparing it to the embedded integrity value stored in embedded integrity value register 240 .
- Integrity check processing module 210 may determine the measured integrity value of the device 105 by aggregating one or more sector values of other processing modules on the device 105 .
- the integrity check processing module 210 may determine the sector value of communication processing module 215 , measuring processing module 220 , and one or more of the general processing modules 225 .
- the integrity check processing module 210 may then add the sector values of these processing modules such that the measured integrity value is the sum of these sector values.
- the integrity check processing module 210 may calculate a checksum based on the sector values of one or more predetermined processing modules.
- Integrity check processing module 210 may determine the measured integrity value using any of a number of formulas while remaining within the scope of the present disclosure.
- the formulas may be a function of other factors in addition to the sector values, such as the time of day, the date, the amplitude of ambient light around the device, the ambient temperature around the device, proximity to a gateway 110 or backend server 115 , and/or the amount of meter usage in the case where device 105 is a smart meter.
- the value stored in the embedded value register may change depending on the values of these other factors in accordance with the formula. The use of varying formulas when performing the integrity check may reduce the risk of compromises to device 105 from nefarious third-parties.
- the integrity check processing module 210 may be programmed to compare the measured integrity value against an aggregate of each of the embedded integrity value registers 240 . Alternatively, integrity check processing module 210 may compare the measured integrity value against an aggregate of a subset of the integrity value registers 240 . In some embodiments, integrity check processing module 210 may be configured to compute multiple measured integrity values. Integrity check processing module 210 may compare one or more measured integrity values to one or more of the embedded integrity values. Integrity check processing module 210 may report the results of the multiple comparisons to control processing module 205 . A policy stored in policy repository may provide instructions depending on the results of the comparison as further described below.
- integrity check processing module 210 may store intermediate measured values in addition to the measured integrity value discussed above, which may also be called a final measured integrity value. These intermediate values may be based on a subset of the sector values used to determine the final measured integrity value. For example, a first intermediate value may be based on the sector values of the communication processing module 215 and the measuring processing module 220 . A second intermediate value may be based on the sector values of communication processing module 215 , measuring processing module 220 , and one of general processing modules 225 . In certain embodiments, the first intermediate value may be the sum of the sector values of communication processing module 215 and measuring processing module 220 .
- the second intermediate value may be the sum of the sector values of communication processing module 215 , measuring processing module 220 , and the one of general processing modules 225 .
- Integrity check processing module 210 may store these intermediate values in general storage 235 .
- Control processing module 205 may access these values from general storage 205 in accordance with a policy stored in policy repository 230 .
- Integrity check processing module 210 may report the result of the comparison of the measured integrity value to the value in embedded integrity value register 240 to control processing module 205 .
- Control processing module 205 may operate to apply one or more policies in policy repository 230 based on the results of an integrity check performed by integrity check processing module 210 .
- Policy repository 230 may be a part of a protected section of the device 105 in a fashion similar to that described above for device identifier register 245 . The level of protection for policy repository 230 may make the individual policies more tamper-proof under certain circumstances.
- the policy may instruct control processing module 205 to modify the operable features of one or more processing modules of device 105 .
- the policy may instruct the control processing module 205 to disable one or more processing modules on the device 105 .
- the control processing module 205 may disable or otherwise restrict the features of communication processing module 215 , the measuring processing module 220 , or one or more of the general processing modules 225 .
- the communication processing module 215 may be operable with a full feature set such that it can communicate with any other device 105 and communicate any type of data to any other device 105 .
- control processing module 205 may completely disable the features of communication processing module 215 or limit its communication features to communicating certain data types.
- the communication processing module 215 may be permitted to transmit metering data, but not allowed to transmit either management data or control data.
- the policy may direct control processing module 205 to disable the entire device 105 .
- the default or normal policy of device 105 may provide that certain processing modules of device 105 are disabled. If an enabled processing module of device 105 or an outside actor (such as another device 105 ) request functions performed by a normally disabled processing module of device 105 , the policy may require device 105 to perform an integrity check with integrity check processing module 210 . In some embodiments, the control processing module 205 may enable the normally disabled processing module if the integrity check results in a match in accordance with the description described above. One of skill in the art will recognize that a policy may instruct control processing module 205 to begin, cease, or maintain a level of functionality of various processing modules of device 105 according to the results of an integrity check by integrity check processing module 210 .
- a policy stored in policy repository 230 may instruct the control processing module 205 to retrieve one or more of the intermediate values which may be stored in general storage 235 .
- a policy stored in policy repository 230 may have different provisions depending on certain of the intermediate values. For example, depending on one or more of the intermediate values, the policy may instruct control processing module 205 to disable only one of the processing modules on device 105 . Following this example, it may instruct control processing module 205 to disable one of the general processing modules 225 while leaving other general processing modules 225 and communication processing module 215 to maintain their present functionality. As is the case with a final measured integrity value, certain intermediate values may be expected. Certain intermediate values depend directly on sector values of certain processing modules. The policy may instruct the control processing module 205 to disable the processing module corresponding to the sector value, which, when aggregated with the measured integrity value, yielded the improper result.
- integrity check processing module 210 may report the result of multiple comparisons if, for example, device 105 includes multiple embedded integrity value registers 240 .
- the policy stored in policy repository 230 may provide various options depending on how many of the comparisons fail to match. For example, in a device 105 employing three embedded integrity value registers 240 , the policy may allow continued functionality if one or two comparisons match successfully while the remaining comparison or comparisons result in a non-match. For each of these comparisons, one or more intermediate values may have been determined according to the procedure described above. Integrity check processing module 210 may store one or more of the determined intermediate values for each of the comparison in general storage 235 for later access by control processing module 205 . Control processing module 205 may access one or more of the intermediate values if, for example, a measured integrity value does not match the value stored in an embedded integrity value register 240 .
- a policy stored in policy repository 230 may instruct control processing module 205 to allow communication processing module 215 to attempt to contact backend server 115 if the integrity check fails.
- Backend server 115 may then determine the policy to apply to device 105 .
- device 105 may transmit certain information to backend server 115 . This information may comprise several items including the measured integrity value, the value stored in device identifier register 245 , any intermediate measured values, and/or any other information suitable to assist backend server to determine a policy to apply to device 105 . Based on this information, backend server 115 may transmit a policy for device 105 to apply.
- This policy may instruct control processing module 205 to allow the processing modules 215 , 220 , and/or 225 to begin, cease, or maintain their current functions.
- Backend sever 115 may transmit a policy that instructs control processing module 205 to disable device 105 completely. In certain embodiments, backend server 115 may automatically dispatch a technician to the location of device 105 for on-site troubleshooting.
- Backend server 115 may use an identifier transmitted by device 105 in determining a policy for device 105 to apply. For example, if backend server determines from the identifier that device 105 is located such that it is relied on heavily for communication routes by other devices 105 , it may transmit a policy that instructs device 105 to maintain a full level of functionality for its communication processing module 215 .
- FIG. 3 illustrates an embodiment of a method 300 operable to initiate an integrity check and facilitate application of a policy in accordance with the results of that integrity check.
- the method begins at step 305 where the integrity check processing module of a device 105 computes the measured integrity value for device 105 .
- An embodiment of step 305 is more fully described during the discussion of FIG. 4 .
- the embedded integrity value is compared to the measured integrity value of the device 105 .
- a determination is made as to whether the embedded integrity value matches the measured integrity value. If the values match, then the method carries out the policy for a passed integrity check at step 325 .
- This policy may comprise enabling and/or not disabling one or more features of one or more processing modules of device 105 .
- This policy may comprise disabling and/or not enabling one or more features of one or more processing modules of device 105 .
- the policy may comprise accessing any intermediate values that may be stored in general storage 235 .
- the policy may provide for disabling and/or not enabling one or more features of specific processing modules depending on these intermediate values. For example, if a certain intermediate value is not as expected, then the policy may provide for disabling and/or not enabling one or more features of the specific processing module corresponding to the unexpected intermediate value.
- the policy may also comprise contacting a backend server 115 , sending the backend server 115 certain information, and receiving instruction in the form of a second policy from the backend server 115 .
- the second policy may be based on the information sent.
- the determination as to which policy is to be applied may depend on one or more differences between the measured integrity value and the embedded integrity value.
- the method 300 may comprise steps associated with multiple embedded integrity values and/or multiple measured integrity values.
- the method may include steps directed to applying a policy that makes use of these multiple values. For example, where multiple comparisons take place the policy may favor certain comparisons over other comparisons in the event that all checks do not pass. Following this example, the policy may provide for disabling and/or not enabling one or more features of a processing module when two out of three of the comparisons fail. In some embodiments, the policy may depend on the type of embedded integrity value register (e.g., hardware, software, or firmware) that yielded a failed comparison.
- embedded integrity value register e.g., hardware, software, or firmware
- a device may be programmed to perform method 300 when the device is booted up. In other embodiments, the device may perform method 300 according to a predetermined schedule. For example, the device 105 may be programmed to perform the method 300 at equally spaced time intervals four to six times a day. In other embodiments, the device 105 may be programmed to perform the method 300 during off-peak times, where off-peak times may mean times where network traffic is comparatively lower than other times. In still other embodiments, the device 105 may perform the method 300 in response to a request from outside of the device 105 . For example, backend server 115 may initiate a system-wide integrity check for all devices 105 within a system 100 .
- FIG. 4 illustrates an example embodiment of a method 305 for computing the measured integrity value of a device 105 .
- the method begins at step 405 where the list of sectors to measure in the device 105 is retrieved.
- a sector may correspond or be a part of a particular processing module of device 105 .
- the list of sectors may be predetermined and stored in a protected section of device 105 .
- the first sector in the list retrieved in step 405 is set as the current sector.
- the current sector value is measured.
- the method updates the final measured value of the device 105 based on the current sector value. In embodiments where the measured integrity depends on the sum of sector values, step 420 adds the current sector value to the final measured value. The sum is stored as the final measured value. When the method is complete, the final measured value may be reported back as the measured integrity value of the device 105 .
- the value stored as the final measured value in step 420 is stored as an intermediate measured value. In some embodiments, this intermediate measured value may be used in the event that the final measured value does not match the embedded integrity value of the device 105 .
- a determination is made as to whether there are any more sectors to measure in the list retrieved during step 405 . If there are more sectors to measure, then the next sector is set as the current sector at step 435 and the method continues with step 415 .
- the method continues with step 440 .
- the final measured value is returned as the measured integrity value for the device 105 . In certain embodiments, the method 305 may return the intermediate measured values. These can be stored in the general storage of the device 105 .
- method 305 may perform its steps in varying orders and with less or more steps than those provided in FIG. 4 .
- method 305 may aggregate all the sector values without storing any intermediate values.
- method 305 may store only some of the intermediate values in accordance with a policy that does not have provisions for all intermediate values.
- method 305 may perform in parallel all the calculations needed to determine the final measured values and intermediate measured values. These embodiments may not require “looping” but may require more system resources to perform simultaneous calculations.
- FIG. 5 illustrates an embodiment of a system 500 operable to facilitate application of a policy to a device. Included in the system are a device 505 , a device 510 , and a backend server 515 .
- Devices 505 and 510 may have features and components similar to device 105 as depicted in FIG. 2 .
- device 505 attempts to communicate to device 510 or to backend server 515 via device 510 .
- Device 505 may attempt to send different types of data including control data, management data, or metering data.
- Device 505 may also attempt to send diagnostic data to backend server 515 in response to a failed integrity check.
- Diagnostic data may include a measured integrity value, an identifier, an intermediate measured value, and any other information that may help backend server 515 to determine an appropriate policy for a device that has failed an integrity check.
- device 505 may have a policy of performing an integrity check on itself before it allows its communication processing module 215 to send the data. If the integrity check fails, device 505 may carry out the policy for a failed integrity check in accordance with method 320 . In the instance that the integrity check passes, device 505 may continue its attempt to send data to device 510 and/or backend server 515 . In the event that the integrity check fails, device 505 may disable or not enable one or more features. In some embodiments, device 505 may attempt to contact backend server 515 via device 510 . Backend server 515 may then send instructions in the form of a policy back to device 505 via device 510 .
- device 510 may receive a request to communicate from device 505 and require device 505 to perform an integrity check.
- Device 510 may require device 505 to transmit the measured integrity value of device 505 to the device 510 .
- Device 510 may then check the measured integrity value of the device 505 against the embedded integrity value of device 510 . In the event that the embedded integrity value of device 510 and the measured integrity value of the device 505 match, device 510 may determine that the device 505 is trustworthy.
- Device 510 may then allow processing of the data that was sent to device 510 from device 505 .
- device 510 may have several options depending on the policy.
- the policy stored in device 510 may be to determine that device 505 is untrustworthy and reject all communication with device 505 .
- Another policy may be to contact backend server 515 for further instruction on how to deal with the incoming communication from device 505 .
- device 510 may forward diagnostic data received from device 505 such that backend server 515 may determine the appropriate policy for the device 510 to follow.
- the determination as to which policy is to be applied may depend on one or more differences between the measured integrity value and the embedded integrity value.
- the policy (either the one stored on the device 510 or the policy received from the backend server 515 ) may have different provisions depending on the data type. For example, if device 505 is attempting to send metering data or diagnostic data, then device 510 may allow processing of the data in accordance with its policy without requiring an integrity check of device 505 . If the type of data being forwarded from device 505 is control data and/or management data, device 510 may restrict the processing on that data in accordance with its policy. This restriction may include rejecting that type of communication or limiting it to certain types of processing.
- device 505 may attempt to join an existing network of devices if it detects that such a network exists when it boots up. In the event that no network exists, it may attempt to begin its own network. If device 505 attempts to join an existing network through device 510 , then device 510 may require device 505 to perform an integrity check similar to that described in the discussion above.
- the device 505 may require device 510 to submit to an integrity check where the device 510 would have to measure its own integrity value and transmit that to the device 505 .
- the device 505 would check the measured integrity value of the device 510 against the embedded integrity value of the device 505 .
- a measured integrity value may be based on sector values, which may be stored in less protected sections of the device 105 . These less protected sectors may be modified sometime after an initial integrity check. This may mean that the results of an integrity check for a device may change over time. For example, a device that passed its integrity check at boot-up may subsequently fail an integrity check after processing various data from other devices on the network. Therefore, certain devices may require subsequent integrity checks from certain other devices even though the other devices may already be admitted to the network.
- the device 510 may issue a certificate to the device 505 indicating a certain level of trust for device 505 . If the embedded integrity value of device 510 matches the measured integrity value transmitted by device 505 , then the certificate may indicate that device 505 has a high level of trustworthiness. If the embedded integrity value of device 510 does not match the measured integrity value transmitted by device 505 , device 505 may require the device 505 to transmit diagnostic data. Based on the diagnostic data, device 510 may issue a certificate with an appropriate level of trust according to a policy. The level of trust may be associated with certain allowed types of processing on the data transmitted from device 505 . Device 510 may also send the diagnostic data transmitted by device 505 to backend server 515 . Based on the diagnostic data, backend server 515 may instruct device 510 to issue a certificate to device 505 indicating a level of trust.
- Device 505 may present the certificate when attempting future communications with the device 510 such that device 510 may not require device 505 to perform a new integrity check the next time it attempts to communicate.
- device 510 may keep the certificate in its own general storage.
- device 510 may associate the certificate with an identifier transmitted by device 505 .
- the certificate may expire after a specified amount of time.
- device 510 may require a new integrity check in certain circumstances. For example, device 510 may require device 505 to perform another integrity check and send its measured integrity value if the type of data that device 505 is attempting to send is of a critical nature.
- certificates may require device 510 to retain and manage certificates of the device 505 and other devices not shown in FIG. 5 .
- Certain embodiments of a system 500 may forego the use of certificates and, instead, require the transmitting device to submit to an integrity check each time it attempts to communicate.
- device 505 may attempt to transmit data to device 510 that was transmitted to device 505 from another device not shown in FIG. 5 .
- device 510 may determine that device 505 was not the original source of the data.
- Device 510 may request that the device that transmitted the data to device 505 perform an integrity check and send its measured integrity value to device 510 .
- Device 510 may compare this value to its own embedded integrity value and then process the data depending on the results of the comparison. Note that the device that transmitted the data to device 505 may not be the “original” source of the data.
- Device 510 may request an integrity check from any device in the chain of devices used to route a communication to device 510 .
- the originating device may transmit its measured integrity value with any data that it sends over the network of devices.
- device 510 may possess the measured integrity value of the originating device when it receives the transmission of data from device 505 .
- device 510 may have a policy that requires it to compare its embedded integrity value to the measured integrity value of the device it receives the data from directly and the device that sent the data originally.
- Backend server 515 may also instruct device 510 as to which devices it should request integrity checks from.
- the embedded integrity values of all devices in a network of devices are configured to be the same.
- the measured integrity values of certain devices may be different, however, under varying circumstances. For instance, a new neighborhood in a city may have new devices configured such that their measured integrity values do not match the embedded integrity values of the other devices in the city. In this situation, the new devices in the new neighborhood may properly have different measured integrity values even though they have not otherwise been compromised. In this situation, one of the other devices may contact the backend server to determine what policy to apply to data coming from one of these new devices in accordance with the discussion above.
- device 505 and device 510 may be configured with multiple embedded integrity value registers.
- device 510 may compare the measured integrity value of device 505 against one or more of the values stored in the embedded integrity value registers of device 510 .
- device 505 may have multiple measured integrity values based on various formulas.
- Device 510 may compare each measured integrity value of device 505 to the one or more embedded integrity values of device 510 .
- Device 510 may have policies that provide different instructions depending on the results of the various comparisons similar to those described with respect to device 105 of FIG. 2 .
- FIG. 6 illustrates an embodiment of a method 600 operable to allow a second device to determine a level of trust of a first device that is attempting to communicate with the second device.
- the method begins at step 605 where a second device receives the measured integrity value of the first device.
- the second device compares its embedded integrity value to the measured integrity value transmitted by the first device.
- a determination is made as to whether the two values match. If the two values do not match, then in step 620 the second device may determine that the first device to be untrustworthy, and the communication with the first device may be rejected. If the method determines that the values do match, then at step 625 the second device determines that the first device is trustworthy and continues with the communication from the first device.
- the method 600 could include various other steps.
- the method 600 could include steps that determine different levels of trustworthiness for the first device depending on the measured integrity value of the first device.
- the second device may process the data according to the policy stored on the device.
- the second device may request that the first device transmit more information or diagnostic data.
- This information may include the first device's identifier, one or more intermediate measured values of the first device, and any other information that may assist the second device in determining a level of trust to assign to the first device.
- This information may guide the second device in determining how to process the data transmitted from the first device in accordance with its policy.
- the method may require that the second device contact a backend server.
- the second device may transmit information or diagnostic data from the first device to assist the backend server in determining the level of trust to assign to the first device.
- FIG. 7 illustrates an embodiment of a method 800 operable to facilitate application of a policy associated with transmitting data from a first device to a second device.
- the method begins at step 705 where the first device attempts to send data to a second device.
- a determination is made as to whether at least a portion of the data that first device is attempting to send is in a protected class.
- Data may be in a protected class if it corresponds to more critical data.
- management data and/or control data may be in a protected class while metering data is unprotected. If no portion of the data is in a protected class, the method continues with step 715 where first device continues its attempt to send data to the second device.
- step 720 the measured integrity value of the first device is determined.
- Step 720 may have similar steps as those listed for method 305 depicted in FIG. 4 .
- the measured integrity value of the first device is compared to the embedded integrity value of the first device.
- step 730 a determination is made as to whether the embedded integrity value of the first device matches the measured integrity value of the first device. If the values do match, the method continues with step 715 where the first device continues its attempts to send the data to the second device.
- step 735 the data transmission is restricted in accordance with a policy.
- This restriction may be that the data is not sent at all or that a limited amount of data is sent in the transmission.
- the first device may continue its attempts to send the non-protected portion of the data.
- method 700 may attempt to contact the backend server for further instruction.
- the first device may send information and/or diagnostic data to the backend server to assist the backend server in determining whether the first device should continue its attempts to transmit the data to the second device.
- FIG. 8 illustrates an embodiment of a method 800 operable to facilitate application of a policy associated with receiving data on a second device from a first device.
- the method begins at step 805 where the second device receives data from a first device.
- step 810 a determination is made as to whether at least a portion of the data received from the first device is in a protected class. If the determination is made that no portion of the data is in a protected class, the method continues with step 815 where the second device will process the data from the first device in a normal manner according to its policy.
- step 810 the method continues with step 820 .
- step 820 the measured integrity value of the first device is compared with the embedded integrity value of the second device. If the first device did not initially send its measured integrity value with its initial transmission of data, then the second device may request the first device's measured integrity value at this time.
- step 825 a determination is made as to whether the value of the measured integrity value of the first device matches the embedded integrity value of the second device. If the values match, then the method continues with step 815 where the data transmitted from the first device is processed by the second device in a normal manner.
- step 830 the processing of the data transmitted from the first device is restricted in accordance with the policy of the second device.
- the second device may contact the backend server to determine what processing it should allow on the data transmitted from the first device.
- the second device may send information and/or diagnostic data of the first device to the backend server to assist the backend server in determining whether the second device should restrict the processing of the data sent by the first device.
- method 800 may include the step of requesting from the first device one or more intermediate measured values.
- the policy applied to the data sent from the first device may depend on one or more of these intermediate measured values. Additionally, steps may be performed in any suitable order.
- gateways 110 may be condensed into one gateway 110 .
- the operations of the systems and apparatuses may be performed by more, fewer, or other components.
- the operations of communication processing module 215 and measuring processing module 220 may be performed by one component, or the operations of control processing module 205 may be performed by more than one component.
- operations of the systems and apparatuses may be performed using any suitable logic comprising software, hardware, and/or other logic.
- each refers to each member of a set or each member of a subset of a set.
- a component of the systems and apparatuses disclosed herein may include an interface, logic, memory, and/or other suitable element.
- An interface receives input, sends output, processes the input and/or output, and/or performs other suitable operation.
- An interface may comprise hardware and/or software.
- Logic performs the operations of the component, for example, by executing instructions to generate output from input.
- Logic may include hardware, software, and/or other logic.
- Logic may be encoded in one or more tangible media and may perform operations when executed by a computer.
- Certain logic, such as a processor, may manage the operation of a component. Examples of a processor include one or more computers, one or more microprocessors, one or more applications, and/or other logic.
- the operations of the embodiments may be performed by one or more computer readable media encoded with a computer program, software, computer executable instructions, and/or instructions capable of being executed by a computer.
- the operations of the embodiments may be performed by one or more computer readable media storing, embodied with, and/or encoded with a computer program and/or having a stored and/or an encoded computer program.
- a storage unit, a repository, and a register may comprise memory.
- a memory stores information.
- a memory may comprise one or more non-transitory, tangible, computer-readable, and/or computer-executable storage media. Examples of memory include computer memory (for example, Random Access Memory (RAM) or Read Only Memory (ROM)), mass storage media (for example, a hard disk), removable storage media (for example, a Compact Disk (CD) or a Digital Video Disk (DVD)), database and/or network storage (for example, a server), and/or other computer-readable medium.
- RAM Random Access Memory
- ROM Read Only Memory
- mass storage media for example, a hard disk
- removable storage media for example, a Compact Disk (CD) or a Digital Video Disk (DVD)
- database and/or network storage for example, a server
- network storage for example, a server
Abstract
Device integrity authentication is performed by receiving, at a second device, a measured integrity value from a first device. The measured integrity value of the first device is compared at the second device to an embedded integrity value associated with the second device. A level of trust for the first device is determined by the second device based on the comparison. Application of a policy to the first device is facilitated by the second device based on the comparison.
Description
- This application is a continuation application of U.S. application Ser. No. 12/860,247 filed Aug. 20, 2010.
- This invention relates in general to networked devices and more particularly to a method and system for device integrity authentication.
- Efforts have increased to modernize the nation's aging electrical grid in order to be ready for next generation usage. This modernization has brought digitization to the electric grid with many industrial control components being networked and remotely controlled. However, the details of how these components interconnect and communicate have remained proprietary. With the modernization, more and more devices are added to the network and implemented with open standards and technology. An example of a component being networked is a smart meter deployed at a customer premises that provides meter readings of electrical usage. The deployment of these smart meters is with limited protection or adequate security measures. Some smart meters may be equipped with temper detection mechanisms that can detect when the meter is opened or moved and shutdown or send an alert signal in response thereto. In many implementations, smart meters send critical data from one meter to another. If one meter in the network is compromised, this critical data can be used to adversely affect system operation for illicit gain. Current smart meters have no capability to detect an attack remotely, by insiders, or zero-day attacks that may affect the software executing in the smart meter.
- From the foregoing, it may be appreciated by those skilled in the art that a need has arisen to detect for errors in devices and protect networked devices from remote software tampering or inside attacks. In accordance with the present invention, there is provided a method and system for device integrity authentication that substantially eliminates or greatly reduces disadvantages and problems associated with conventional device security in a network.
- According to one embodiment of the present invention, a method for device integrity authentication is provided that includes receiving, at a second device, a measured integrity value from a first device. The measured integrity value of the first device is compared at the second device to an embedded integrity value associated with the second device. A level of trust for the first device is determined by the second device based on the comparison. Application of a policy to the first device is facilitated by the second device based on the comparison.
- Certain embodiments of the invention may provide one or more technical advantages. An example of a technical advantage of one embodiment is to have a second device perform an integrity check on a first device. Another technical advantage is to apply a policy to the first device based on the results of the integrity authentication.
- Certain embodiments of the invention may include none, some, or all of the above technical advantages. One or more other technical advantages may be readily apparent to one skilled in the art from the figures, descriptions, and claims included herein.
- For a more complete understanding of the present invention and for further features and advantages thereof, reference is now made to the following description taken in conjunction with the accompanying drawings, wherein like reference numerals represent like parts, in which:
-
FIG. 1 illustrates an example embodiment of a system with networked devices; -
FIG. 2 illustrates an example embodiment of a device in the network; -
FIG. 3 illustrates an example embodiment of a method for performing an integrity check within the device; -
FIG. 4 illustrates an example embodiment of a method for computing a measured integrity value of the device; -
FIG. 5 illustrates an example embodiment of a system with two devices and a backend server; -
FIG. 6 illustrates an example embodiment of a method to allow a second device to determine a level of trust for a first device; -
FIG. 7 illustrates an example embodiment of a method involved in transmitting data from the first device to the second device; -
FIG. 8 illustrates an example embodiment of a method involved in receiving data at the second device from the first device. -
FIG. 1 illustrates an embodiment of asystem 100 operable to facilitate the application of a policy to one ormore devices 105. In this embodiment, thesystem 100 includes anetwork comprising devices 105,gateways 110, and abackend server 115.Devices 105 may be operable to communicate with one another and to thegateways 110.Devices 105, in certain embodiments, may communicate directly with thebackend server 115 or through agateway 110. As will be described in more detail in the following figures, under various circumstances, adevice 105 may take certain actions in accordance with a policy.Device 105 may store the policy within local storage, or, alternatively, an outside source may communicate the policy todevice 105. For example, the policy may come fromother devices 105, frombackend server 115 viagateway 110 and/orother devices 105, or frombackend server 115 directly. -
Devices 105,gateways 110, andbackend server 115 may be coupled to any suitable communication network. A communication network may comprise all or a portion of one or more of the following: a public switched telephone network (PSTN), a public or private data network, a local area network (LAN), a metropolitan area network (MAN), a wide area network (WAN), a local, regional, or global communication or computer network such as the Internet, a wireline or wireless network, an enterprise intranet, other suitable communication link, or any combination of any of the preceding. For example, in certain embodiments,gateways 110 may be connected by fiber backbone to backendserver 115. Additionally,devices 105 may comprise radio transmitters operable to transmit data from adevice 105 wirelessly toother devices 105,gateways 110, andbackend server 115. - In particular embodiments of
system 100,devices 105 may operate as smart meters operable to measure electricity usage for customers of an electric utility. Whendevices 105 act as smart meters, they may form a mesh network in which management data, control data, and meter data are transmitted from device to device with each device serving as a relay node. In these embodiments,backend server 115 may be located at an electric utility company. Meter data may comprise information about the electric usage at a particular customer's premises. Control data may comprise data associated with controlling particular components on one ormore devices 105. Management data may comprise data associated with forming and maintaining the network. For example, management data could indicate the route that data from aparticular device 105 would take in order to reachbackend server 115. As described more fully in the description for the figures that follow, a policy may be associated with these different types of data. - In other embodiments,
devices 105 may be any of a range of devices. For example, in addition to smart meters, thedevices 105 could comprise several of the other components of a smart electricity grid. More broadly speaking, thedevices 105 may comprise one or more components of any supervisory control and data acquisition (SCADA) or industrial control system. In other embodiments, thedevices 105 may be any device deployed on a home area network (HAN). One having ordinary skill in the art will appreciate thatdevices 105 may be employed in a comparatively small network such as a HAN or deployed as a large scale network, such as an electric grid deployed over a neighborhood or city. -
FIG. 2 illustrates an embodiment of adevice 105 operable to facilitate application of a policy. In certain embodiments,device 105 may include acontrol processing module 205, which may have general control over the operations and features ofdevice 105.Control processing module 205 may be coupled to several processing modules operable to perform different functions ofdevice 105 such as integritycheck processing module 210,communication processing module 215, measuringprocessing module 220, and othergeneral processing modules 225. These processing modules may perform various functions. In some embodiments,control processing module 205 also may be coupled to apolicy repository 230, ageneral storage 235, and/or adevice identifier register 245.Policy repository 230 may contain policies to be applied todevice 105 under certain conditions.General storage 235 may comprise a storage unit generally accessible bycontrol processing module 205 and the other processing modules included ondevice 105.Device identifier register 245 may be configurable to contain the value of an identifier ofdevice 105. -
Communication processing module 215, measuringprocessing module 220, andgeneral processing modules 225 may perform a wide range of functions. In certain embodiments,communication processing module 215 may operate to transmit or receive communications fromother devices 105,gateways 110,backend server 115, or any other external source. It also may operate to assist in determining the route a certain communication will take to get to a specific destination. For example, it may determine whichother devices 105 to communicate with in order for a transmission of data to get to a particularother device 105, aparticular gateway 110, orbackend server 115. In embodiments wheredevice 105 is an electric smart meter, measuringprocessing module 220 may measure electricity usage for an electricity user's premises.General processing modules 225 may perform any of a number functions such as measuring ambient environment factors proximate todevice 105, testing of various elements ofdevice 105, and maintaining an appropriate temperature fordevice 105.Communication processing module 215, measuringprocessing module 220, andgeneral processing modules 225 may operate under the direction ofcontrol processing module 205 according to a policy stored inpolicy repository 230. - In embodiments that include
device identifier register 245, an identifier ofdevice 105 may be used to determine what policy should apply todevice 105 as described in more detail below. As non-limiting examples, an identifier may comprise a Media Access Control (MAC) address or an (Internet Protocol) IP address. The identifier may be hardwired or hardcoded intodevice identifier register 245 at run-time, or alternatively may be updatable after deployment ofdevice 105. An identifier may be unique in the sense that it uniquely identifies aparticular device 105 in a plurality ofdevices 105. Alternatively, the identifier contained withindevice identifier register 245 of aparticular device 105 may be the same as an identifier for one or moreother devices 105. This may happen, for example, in a city with many neighborhoods. The devices common to a particular neighborhood may share a common identifier. Certain embodiments ofdevice 105 may include none, one, two, or more device identifier registers 245. They may be configured to contain any combination of the types of identifiers discussed herein. - In certain embodiments,
device identifier register 245 may be in a protected section ofdevice 105, such thatdevice identifier register 245 is more difficult to modify oncedevice 105 is deployed in the field. The protected section ofdevice 105 could be configured in hardware, software, or firmware. For example,device identifier register 245 may be a part of read-only memory or computed from a program configured to be non-modifiable. - An embedded
integrity value register 240 may store a value which can be accessed by integritycheck processing module 210 when performing its integrity check, as further described below. The value stored in embeddedintegrity value register 240 may be programmed at the time of the manufacture ofdevice 105. Alternatively, it may be programmed at some later time. Embeddedintegrity value register 240 may be a part of a protected section of thedevice 105 in a similar fashion as that described above fordevice identifier register 245. In some embodiments,device 105 may employ multiple embedded integrity value registers 240. In certain of these embodiments, the embedded integrity value registers may employ various formats, such as hardware, firmware, or software. This approach may allow redundancy in the integrity checking feature of integritycheck processing module 210 as further described below. - In certain embodiments, integrity
check processing module 210 may be operable to perform an integrity check by determining a measured integrity value of thedevice 105 and comparing it to the embedded integrity value stored in embeddedintegrity value register 240. Integritycheck processing module 210 may determine the measured integrity value of thedevice 105 by aggregating one or more sector values of other processing modules on thedevice 105. For example, the integritycheck processing module 210 may determine the sector value ofcommunication processing module 215, measuringprocessing module 220, and one or more of thegeneral processing modules 225. The integritycheck processing module 210 may then add the sector values of these processing modules such that the measured integrity value is the sum of these sector values. In other embodiments, the integritycheck processing module 210 may calculate a checksum based on the sector values of one or more predetermined processing modules. - Integrity
check processing module 210 may determine the measured integrity value using any of a number of formulas while remaining within the scope of the present disclosure. In certain embodiments, the formulas may be a function of other factors in addition to the sector values, such as the time of day, the date, the amplitude of ambient light around the device, the ambient temperature around the device, proximity to agateway 110 orbackend server 115, and/or the amount of meter usage in the case wheredevice 105 is a smart meter. In certain of these embodiments, the value stored in the embedded value register may change depending on the values of these other factors in accordance with the formula. The use of varying formulas when performing the integrity check may reduce the risk of compromises todevice 105 from nefarious third-parties. - In certain embodiments employing multiple embedded integrity value registers 240, the integrity
check processing module 210 may be programmed to compare the measured integrity value against an aggregate of each of the embedded integrity value registers 240. Alternatively, integritycheck processing module 210 may compare the measured integrity value against an aggregate of a subset of the integrity value registers 240. In some embodiments, integritycheck processing module 210 may be configured to compute multiple measured integrity values. Integritycheck processing module 210 may compare one or more measured integrity values to one or more of the embedded integrity values. Integritycheck processing module 210 may report the results of the multiple comparisons to controlprocessing module 205. A policy stored in policy repository may provide instructions depending on the results of the comparison as further described below. - In certain embodiments, integrity
check processing module 210 may store intermediate measured values in addition to the measured integrity value discussed above, which may also be called a final measured integrity value. These intermediate values may be based on a subset of the sector values used to determine the final measured integrity value. For example, a first intermediate value may be based on the sector values of thecommunication processing module 215 and the measuringprocessing module 220. A second intermediate value may be based on the sector values ofcommunication processing module 215, measuringprocessing module 220, and one ofgeneral processing modules 225. In certain embodiments, the first intermediate value may be the sum of the sector values ofcommunication processing module 215 and measuringprocessing module 220. The second intermediate value may be the sum of the sector values ofcommunication processing module 215, measuringprocessing module 220, and the one ofgeneral processing modules 225. Integritycheck processing module 210 may store these intermediate values ingeneral storage 235.Control processing module 205 may access these values fromgeneral storage 205 in accordance with a policy stored inpolicy repository 230. - Integrity
check processing module 210 may report the result of the comparison of the measured integrity value to the value in embeddedintegrity value register 240 to controlprocessing module 205.Control processing module 205 may operate to apply one or more policies inpolicy repository 230 based on the results of an integrity check performed by integritycheck processing module 210.Policy repository 230 may be a part of a protected section of thedevice 105 in a fashion similar to that described above fordevice identifier register 245. The level of protection forpolicy repository 230 may make the individual policies more tamper-proof under certain circumstances. - Depending on the results of the comparison, the policy may instruct
control processing module 205 to modify the operable features of one or more processing modules ofdevice 105. In certain embodiments, if the values do not match, the policy may instruct thecontrol processing module 205 to disable one or more processing modules on thedevice 105. For example, thecontrol processing module 205 may disable or otherwise restrict the features ofcommunication processing module 215, the measuringprocessing module 220, or one or more of thegeneral processing modules 225. In normal operation thecommunication processing module 215 may be operable with a full feature set such that it can communicate with anyother device 105 and communicate any type of data to anyother device 105. In the instance that the measured integrity value does not match the embedded integrity value, thecontrol processing module 205, according to the policy, may completely disable the features ofcommunication processing module 215 or limit its communication features to communicating certain data types. In certain embodiments, thecommunication processing module 215 may be permitted to transmit metering data, but not allowed to transmit either management data or control data. In other embodiments, the policy may directcontrol processing module 205 to disable theentire device 105. - In certain embodiments, the default or normal policy of
device 105 may provide that certain processing modules ofdevice 105 are disabled. If an enabled processing module ofdevice 105 or an outside actor (such as another device 105) request functions performed by a normally disabled processing module ofdevice 105, the policy may requiredevice 105 to perform an integrity check with integritycheck processing module 210. In some embodiments, thecontrol processing module 205 may enable the normally disabled processing module if the integrity check results in a match in accordance with the description described above. One of skill in the art will recognize that a policy may instructcontrol processing module 205 to begin, cease, or maintain a level of functionality of various processing modules ofdevice 105 according to the results of an integrity check by integritycheck processing module 210. - In the event that a final measured integrity value does not match the embedded integrity value, a policy stored in
policy repository 230 may instruct thecontrol processing module 205 to retrieve one or more of the intermediate values which may be stored ingeneral storage 235. A policy stored inpolicy repository 230 may have different provisions depending on certain of the intermediate values. For example, depending on one or more of the intermediate values, the policy may instructcontrol processing module 205 to disable only one of the processing modules ondevice 105. Following this example, it may instructcontrol processing module 205 to disable one of thegeneral processing modules 225 while leaving othergeneral processing modules 225 andcommunication processing module 215 to maintain their present functionality. As is the case with a final measured integrity value, certain intermediate values may be expected. Certain intermediate values depend directly on sector values of certain processing modules. The policy may instruct thecontrol processing module 205 to disable the processing module corresponding to the sector value, which, when aggregated with the measured integrity value, yielded the improper result. - In certain embodiments, integrity
check processing module 210 may report the result of multiple comparisons if, for example,device 105 includes multiple embedded integrity value registers 240. In embodiments with multiple embedded integrity value registers 240, the policy stored inpolicy repository 230 may provide various options depending on how many of the comparisons fail to match. For example, in adevice 105 employing three embedded integrity value registers 240, the policy may allow continued functionality if one or two comparisons match successfully while the remaining comparison or comparisons result in a non-match. For each of these comparisons, one or more intermediate values may have been determined according to the procedure described above. Integritycheck processing module 210 may store one or more of the determined intermediate values for each of the comparison ingeneral storage 235 for later access bycontrol processing module 205.Control processing module 205 may access one or more of the intermediate values if, for example, a measured integrity value does not match the value stored in an embeddedintegrity value register 240. - In certain embodiments, a policy stored in
policy repository 230 may instructcontrol processing module 205 to allowcommunication processing module 215 to attempt to contactbackend server 115 if the integrity check fails.Backend server 115 may then determine the policy to apply todevice 105. To assistbackend server 115 in determining what functions thedevice 105 should be allowed to perform,device 105 may transmit certain information tobackend server 115. This information may comprise several items including the measured integrity value, the value stored indevice identifier register 245, any intermediate measured values, and/or any other information suitable to assist backend server to determine a policy to apply todevice 105. Based on this information,backend server 115 may transmit a policy fordevice 105 to apply. This policy, similar to the policy that may be stored inpolicy repository 230, may instructcontrol processing module 205 to allow theprocessing modules control processing module 205 to disabledevice 105 completely. In certain embodiments,backend server 115 may automatically dispatch a technician to the location ofdevice 105 for on-site troubleshooting. -
Backend server 115, in some embodiments, may use an identifier transmitted bydevice 105 in determining a policy fordevice 105 to apply. For example, if backend server determines from the identifier thatdevice 105 is located such that it is relied on heavily for communication routes byother devices 105, it may transmit a policy that instructsdevice 105 to maintain a full level of functionality for itscommunication processing module 215. -
FIG. 3 illustrates an embodiment of amethod 300 operable to initiate an integrity check and facilitate application of a policy in accordance with the results of that integrity check. The method begins atstep 305 where the integrity check processing module of adevice 105 computes the measured integrity value fordevice 105. An embodiment ofstep 305 is more fully described during the discussion ofFIG. 4 . Atstep 310, the embedded integrity value is compared to the measured integrity value of thedevice 105. At step 315 a determination is made as to whether the embedded integrity value matches the measured integrity value. If the values match, then the method carries out the policy for a passed integrity check atstep 325. This policy may comprise enabling and/or not disabling one or more features of one or more processing modules ofdevice 105. - If the values do not match in
step 315, the method then carries out the policy for a failed integrity check atstep 320. This policy may comprise disabling and/or not enabling one or more features of one or more processing modules ofdevice 105. The policy may comprise accessing any intermediate values that may be stored ingeneral storage 235. The policy may provide for disabling and/or not enabling one or more features of specific processing modules depending on these intermediate values. For example, if a certain intermediate value is not as expected, then the policy may provide for disabling and/or not enabling one or more features of the specific processing module corresponding to the unexpected intermediate value. The policy may also comprise contacting abackend server 115, sending thebackend server 115 certain information, and receiving instruction in the form of a second policy from thebackend server 115. The second policy may be based on the information sent. The determination as to which policy is to be applied may depend on one or more differences between the measured integrity value and the embedded integrity value. - Other embodiments of the
method 300 may comprise steps associated with multiple embedded integrity values and/or multiple measured integrity values. In these embodiments, the method may include steps directed to applying a policy that makes use of these multiple values. For example, where multiple comparisons take place the policy may favor certain comparisons over other comparisons in the event that all checks do not pass. Following this example, the policy may provide for disabling and/or not enabling one or more features of a processing module when two out of three of the comparisons fail. In some embodiments, the policy may depend on the type of embedded integrity value register (e.g., hardware, software, or firmware) that yielded a failed comparison. - In certain embodiments, a device may be programmed to perform
method 300 when the device is booted up. In other embodiments, the device may performmethod 300 according to a predetermined schedule. For example, thedevice 105 may be programmed to perform themethod 300 at equally spaced time intervals four to six times a day. In other embodiments, thedevice 105 may be programmed to perform themethod 300 during off-peak times, where off-peak times may mean times where network traffic is comparatively lower than other times. In still other embodiments, thedevice 105 may perform themethod 300 in response to a request from outside of thedevice 105. For example,backend server 115 may initiate a system-wide integrity check for alldevices 105 within asystem 100. -
FIG. 4 illustrates an example embodiment of amethod 305 for computing the measured integrity value of adevice 105. The method begins atstep 405 where the list of sectors to measure in thedevice 105 is retrieved. A sector may correspond or be a part of a particular processing module ofdevice 105. In some embodiments, the list of sectors may be predetermined and stored in a protected section ofdevice 105. - At
step 410, the first sector in the list retrieved instep 405 is set as the current sector. Atstep 415, the current sector value is measured. Atstep 420, the method updates the final measured value of thedevice 105 based on the current sector value. In embodiments where the measured integrity depends on the sum of sector values,step 420 adds the current sector value to the final measured value. The sum is stored as the final measured value. When the method is complete, the final measured value may be reported back as the measured integrity value of thedevice 105. - At
step 425, the value stored as the final measured value instep 420 is stored as an intermediate measured value. In some embodiments, this intermediate measured value may be used in the event that the final measured value does not match the embedded integrity value of thedevice 105. Atstep 430, a determination is made as to whether there are any more sectors to measure in the list retrieved duringstep 405. If there are more sectors to measure, then the next sector is set as the current sector atstep 435 and the method continues withstep 415. Atstep 430, if there are no more sectors to measure, the method continues withstep 440. Atstep 440, the final measured value is returned as the measured integrity value for thedevice 105. In certain embodiments, themethod 305 may return the intermediate measured values. These can be stored in the general storage of thedevice 105. - In certain embodiments,
method 305 may perform its steps in varying orders and with less or more steps than those provided inFIG. 4 . For example,method 305 may aggregate all the sector values without storing any intermediate values. Alternatively,method 305 may store only some of the intermediate values in accordance with a policy that does not have provisions for all intermediate values. In some embodiments,method 305 may perform in parallel all the calculations needed to determine the final measured values and intermediate measured values. These embodiments may not require “looping” but may require more system resources to perform simultaneous calculations. -
FIG. 5 illustrates an embodiment of asystem 500 operable to facilitate application of a policy to a device. Included in the system are adevice 505, adevice 510, and abackend server 515.Devices device 105 as depicted inFIG. 2 . In certain embodiments,device 505 attempts to communicate todevice 510 or tobackend server 515 viadevice 510.Device 505 may attempt to send different types of data including control data, management data, or metering data.Device 505 may also attempt to send diagnostic data tobackend server 515 in response to a failed integrity check. Diagnostic data may include a measured integrity value, an identifier, an intermediate measured value, and any other information that may helpbackend server 515 to determine an appropriate policy for a device that has failed an integrity check. Depending on the type of data,device 505 may have a policy of performing an integrity check on itself before it allows itscommunication processing module 215 to send the data. If the integrity check fails,device 505 may carry out the policy for a failed integrity check in accordance withmethod 320. In the instance that the integrity check passes,device 505 may continue its attempt to send data todevice 510 and/orbackend server 515. In the event that the integrity check fails,device 505 may disable or not enable one or more features. In some embodiments,device 505 may attempt to contactbackend server 515 viadevice 510.Backend server 515 may then send instructions in the form of a policy back todevice 505 viadevice 510. - In certain embodiments,
device 510 may receive a request to communicate fromdevice 505 and requiredevice 505 to perform an integrity check.Device 510 may requiredevice 505 to transmit the measured integrity value ofdevice 505 to thedevice 510.Device 510 may then check the measured integrity value of thedevice 505 against the embedded integrity value ofdevice 510. In the event that the embedded integrity value ofdevice 510 and the measured integrity value of thedevice 505 match,device 510 may determine that thedevice 505 is trustworthy.Device 510 may then allow processing of the data that was sent todevice 510 fromdevice 505. - In the event that the embedded integrity value of
device 510 and the measured integrity value ofdevice 505 do not match,device 510 may have several options depending on the policy. The policy stored indevice 510 may be to determine thatdevice 505 is untrustworthy and reject all communication withdevice 505. Another policy may be to contactbackend server 515 for further instruction on how to deal with the incoming communication fromdevice 505. In seeking instruction frombackend server 515,device 510 may forward diagnostic data received fromdevice 505 such thatbackend server 515 may determine the appropriate policy for thedevice 510 to follow. The determination as to which policy is to be applied may depend on one or more differences between the measured integrity value and the embedded integrity value. - In certain embodiments, the policy (either the one stored on the
device 510 or the policy received from the backend server 515) may have different provisions depending on the data type. For example, ifdevice 505 is attempting to send metering data or diagnostic data, thendevice 510 may allow processing of the data in accordance with its policy without requiring an integrity check ofdevice 505. If the type of data being forwarded fromdevice 505 is control data and/or management data,device 510 may restrict the processing on that data in accordance with its policy. This restriction may include rejecting that type of communication or limiting it to certain types of processing. - In certain embodiments,
device 505 may attempt to join an existing network of devices if it detects that such a network exists when it boots up. In the event that no network exists, it may attempt to begin its own network. Ifdevice 505 attempts to join an existing network throughdevice 510, thendevice 510 may requiredevice 505 to perform an integrity check similar to that described in the discussion above. - If admitted to the network, the
device 505 may requiredevice 510 to submit to an integrity check where thedevice 510 would have to measure its own integrity value and transmit that to thedevice 505. Thedevice 505 would check the measured integrity value of thedevice 510 against the embedded integrity value of thedevice 505. A measured integrity value may be based on sector values, which may be stored in less protected sections of thedevice 105. These less protected sectors may be modified sometime after an initial integrity check. This may mean that the results of an integrity check for a device may change over time. For example, a device that passed its integrity check at boot-up may subsequently fail an integrity check after processing various data from other devices on the network. Therefore, certain devices may require subsequent integrity checks from certain other devices even though the other devices may already be admitted to the network. - In certain embodiments, the
device 510 may issue a certificate to thedevice 505 indicating a certain level of trust fordevice 505. If the embedded integrity value ofdevice 510 matches the measured integrity value transmitted bydevice 505, then the certificate may indicate thatdevice 505 has a high level of trustworthiness. If the embedded integrity value ofdevice 510 does not match the measured integrity value transmitted bydevice 505,device 505 may require thedevice 505 to transmit diagnostic data. Based on the diagnostic data,device 510 may issue a certificate with an appropriate level of trust according to a policy. The level of trust may be associated with certain allowed types of processing on the data transmitted fromdevice 505.Device 510 may also send the diagnostic data transmitted bydevice 505 tobackend server 515. Based on the diagnostic data,backend server 515 may instructdevice 510 to issue a certificate todevice 505 indicating a level of trust. -
Device 505 may present the certificate when attempting future communications with thedevice 510 such thatdevice 510 may not requiredevice 505 to perform a new integrity check the next time it attempts to communicate. In some embodiments,device 510 may keep the certificate in its own general storage. In these embodiments,device 510 may associate the certificate with an identifier transmitted bydevice 505. In particular embodiments, the certificate may expire after a specified amount of time. Even with the presence of a certificate,device 510 may require a new integrity check in certain circumstances. For example,device 510 may requiredevice 505 to perform another integrity check and send its measured integrity value if the type of data thatdevice 505 is attempting to send is of a critical nature. The use of certificates, in certain embodiments, may requiredevice 510 to retain and manage certificates of thedevice 505 and other devices not shown inFIG. 5 . Certain embodiments of asystem 500 may forego the use of certificates and, instead, require the transmitting device to submit to an integrity check each time it attempts to communicate. - In certain embodiments,
device 505 may attempt to transmit data todevice 510 that was transmitted todevice 505 from another device not shown inFIG. 5 . In some embodiments,device 510 may determine thatdevice 505 was not the original source of the data.Device 510 may request that the device that transmitted the data todevice 505 perform an integrity check and send its measured integrity value todevice 510.Device 510 may compare this value to its own embedded integrity value and then process the data depending on the results of the comparison. Note that the device that transmitted the data todevice 505 may not be the “original” source of the data.Device 510 may request an integrity check from any device in the chain of devices used to route a communication todevice 510. In certain embodiments, the originating device may transmit its measured integrity value with any data that it sends over the network of devices. As such,device 510 may possess the measured integrity value of the originating device when it receives the transmission of data fromdevice 505. In some embodiments,device 510 may have a policy that requires it to compare its embedded integrity value to the measured integrity value of the device it receives the data from directly and the device that sent the data originally.Backend server 515 may also instructdevice 510 as to which devices it should request integrity checks from. - In some embodiments, the embedded integrity values of all devices in a network of devices are configured to be the same. The measured integrity values of certain devices may be different, however, under varying circumstances. For instance, a new neighborhood in a city may have new devices configured such that their measured integrity values do not match the embedded integrity values of the other devices in the city. In this situation, the new devices in the new neighborhood may properly have different measured integrity values even though they have not otherwise been compromised. In this situation, one of the other devices may contact the backend server to determine what policy to apply to data coming from one of these new devices in accordance with the discussion above.
- All of the options discussed regarding integrity checks for one device with respect to
FIG. 2 are also available when a first device attempts to communicate with a second device. For example,device 505 anddevice 510 may be configured with multiple embedded integrity value registers. Whendevice 505 attempts to communicate withdevice 510,device 510 may compare the measured integrity value ofdevice 505 against one or more of the values stored in the embedded integrity value registers ofdevice 510. In some embodiments,device 505 may have multiple measured integrity values based on various formulas.Device 510 may compare each measured integrity value ofdevice 505 to the one or more embedded integrity values ofdevice 510.Device 510 may have policies that provide different instructions depending on the results of the various comparisons similar to those described with respect todevice 105 ofFIG. 2 . -
FIG. 6 illustrates an embodiment of amethod 600 operable to allow a second device to determine a level of trust of a first device that is attempting to communicate with the second device. The method begins atstep 605 where a second device receives the measured integrity value of the first device. Instep 610, the second device compares its embedded integrity value to the measured integrity value transmitted by the first device. Instep 615, a determination is made as to whether the two values match. If the two values do not match, then instep 620 the second device may determine that the first device to be untrustworthy, and the communication with the first device may be rejected. If the method determines that the values do match, then atstep 625 the second device determines that the first device is trustworthy and continues with the communication from the first device. - One of skill in the art will recognize that the
method 600 could include various other steps. For example, themethod 600 could include steps that determine different levels of trustworthiness for the first device depending on the measured integrity value of the first device. Depending on the level of trustworthiness, the second device may process the data according to the policy stored on the device. In the event that the measured integrity value of the first device does not match the embedded integrity value of the second device, the second device may request that the first device transmit more information or diagnostic data. This information may include the first device's identifier, one or more intermediate measured values of the first device, and any other information that may assist the second device in determining a level of trust to assign to the first device. This information may guide the second device in determining how to process the data transmitted from the first device in accordance with its policy. In some embodiments, the method may require that the second device contact a backend server. The second device may transmit information or diagnostic data from the first device to assist the backend server in determining the level of trust to assign to the first device. -
FIG. 7 illustrates an embodiment of amethod 800 operable to facilitate application of a policy associated with transmitting data from a first device to a second device. The method begins atstep 705 where the first device attempts to send data to a second device. Atstep 710, a determination is made as to whether at least a portion of the data that first device is attempting to send is in a protected class. Data may be in a protected class if it corresponds to more critical data. In some embodiments, management data and/or control data may be in a protected class while metering data is unprotected. If no portion of the data is in a protected class, the method continues withstep 715 where first device continues its attempt to send data to the second device. - If the determination is made that at least a portion of that data that the first device seeks to transmit is in a protected class, then the method continues with
step 720 where the measured integrity value of the first device is determined. Step 720 may have similar steps as those listed formethod 305 depicted inFIG. 4 . Instep 725, the measured integrity value of the first device is compared to the embedded integrity value of the first device. Instep 730, a determination is made as to whether the embedded integrity value of the first device matches the measured integrity value of the first device. If the values do match, the method continues withstep 715 where the first device continues its attempts to send the data to the second device. If the method determines that the values do not match, the method continues withstep 735 where the data transmission is restricted in accordance with a policy. This restriction may be that the data is not sent at all or that a limited amount of data is sent in the transmission. For example, the first device may continue its attempts to send the non-protected portion of the data. In some embodiments,method 700 may attempt to contact the backend server for further instruction. The first device may send information and/or diagnostic data to the backend server to assist the backend server in determining whether the first device should continue its attempts to transmit the data to the second device. -
FIG. 8 illustrates an embodiment of amethod 800 operable to facilitate application of a policy associated with receiving data on a second device from a first device. The method begins atstep 805 where the second device receives data from a first device. Instep 810, a determination is made as to whether at least a portion of the data received from the first device is in a protected class. If the determination is made that no portion of the data is in a protected class, the method continues withstep 815 where the second device will process the data from the first device in a normal manner according to its policy. - If the determination is made in
step 810 that at least a portion of the data is in a protected class, then the method continues withstep 820. Instep 820 the measured integrity value of the first device is compared with the embedded integrity value of the second device. If the first device did not initially send its measured integrity value with its initial transmission of data, then the second device may request the first device's measured integrity value at this time. Instep 825, a determination is made as to whether the value of the measured integrity value of the first device matches the embedded integrity value of the second device. If the values match, then the method continues withstep 815 where the data transmitted from the first device is processed by the second device in a normal manner. If the determination is made instep 825 that the values do not match, then the method continues withstep 830 where the processing of the data transmitted from the first device is restricted in accordance with the policy of the second device. In certain embodiments, the second device may contact the backend server to determine what processing it should allow on the data transmitted from the first device. The second device may send information and/or diagnostic data of the first device to the backend server to assist the backend server in determining whether the second device should restrict the processing of the data sent by the first device. - Modifications, additions, or omissions may be made to the methods disclosed herein without departing from the scope of the invention. The methods may include more, fewer, or other steps. For example,
method 800 may include the step of requesting from the first device one or more intermediate measured values. The policy applied to the data sent from the first device may depend on one or more of these intermediate measured values. Additionally, steps may be performed in any suitable order. - Modifications, additions, or omissions may be made to the systems and apparatuses disclosed herein without departing from the scope of the invention. The components of the systems and apparatuses may be integrated or separated. For example,
gateways 110 may be condensed into onegateway 110. Moreover, the operations of the systems and apparatuses may be performed by more, fewer, or other components. For example, the operations ofcommunication processing module 215 and measuringprocessing module 220 may be performed by one component, or the operations ofcontrol processing module 205 may be performed by more than one component. Additionally, operations of the systems and apparatuses may be performed using any suitable logic comprising software, hardware, and/or other logic. As used in this document, “each” refers to each member of a set or each member of a subset of a set. - A component of the systems and apparatuses disclosed herein may include an interface, logic, memory, and/or other suitable element. An interface receives input, sends output, processes the input and/or output, and/or performs other suitable operation. An interface may comprise hardware and/or software.
- Logic performs the operations of the component, for example, by executing instructions to generate output from input. Logic may include hardware, software, and/or other logic. Logic may be encoded in one or more tangible media and may perform operations when executed by a computer. Certain logic, such as a processor, may manage the operation of a component. Examples of a processor include one or more computers, one or more microprocessors, one or more applications, and/or other logic.
- In particular embodiments, the operations of the embodiments may be performed by one or more computer readable media encoded with a computer program, software, computer executable instructions, and/or instructions capable of being executed by a computer. In particular embodiments, the operations of the embodiments may be performed by one or more computer readable media storing, embodied with, and/or encoded with a computer program and/or having a stored and/or an encoded computer program.
- A storage unit, a repository, and a register may comprise memory. A memory stores information. A memory may comprise one or more non-transitory, tangible, computer-readable, and/or computer-executable storage media. Examples of memory include computer memory (for example, Random Access Memory (RAM) or Read Only Memory (ROM)), mass storage media (for example, a hard disk), removable storage media (for example, a Compact Disk (CD) or a Digital Video Disk (DVD)), database and/or network storage (for example, a server), and/or other computer-readable medium.
- Although this disclosure has been described in terms of certain embodiments, alterations and permutations of the embodiments will be apparent to those skilled in the art. Accordingly, the above description of the embodiments does not constrain this disclosure. Other changes, substitutions, and alterations are possible without departing from the spirit and scope of this disclosure, as defined by the following claims.
Claims (22)
1. A method for device integrity authentication, comprising:
receiving, at a second device, a measured integrity value from a first device;
comparing, using the second device, the measured integrity value of the first device to an embedded integrity value associated with the second device;
determining, by the second device, a level of trust for the first device based on the comparison.
2. The method of claim 1 , wherein the level of trust is one of a plurality of levels of trust that can be determined based on the comparison.
3. The method of claim 2 , wherein the plurality of levels of trust include a low level of trust, a medium level of trust, and a high level of trust.
4. The method of claim 3 , wherein determining the level of trust includes determining that the first device has a low level of trust in response to the measured integrity value not matching the embedded integrity value.
5. The method of claim 1 , further comprising:
facilitating, on the second device, application of one of a plurality of communication policies associated with communicating with the first device based on the determined level of trust.
6. The method of claim 5 , wherein one of the plurality of policies includes restricting functions of the first device based on the determined level of trust.
7. The method of claim 5 , wherein one of the plurality of policies includes rejecting all communications with the first device based on the determined level of trust.
8. The method of claim 1 , wherein determining the level of trust includes:
communicating, by the second device, with a backend server in response to the measured integrity value not matching the embedded integrity value;
receiving, at the second device, an indication from the backend server an indication of the level of trust for the first device.
9. The method of claim 1 , wherein determining the level of trust includes:
communicating, by the second device, with a backend server in response to the measured integrity value not matching the embedded integrity value;
receiving, at the second device, one of a plurality of communication policies associated with communicating with the first device from the backend server.
10. The method of claim 1 , wherein determining the level of trust includes:
requesting additional information from the first device in response to the measured integrity value not matching the embedded integrity value;
11. The method of claim 10 , wherein the additional information includes an identity of the first device and one or more intermediate measured integrity values.
12. A system for device integrity authentication, comprising:
an integrity check processing module operable to:
receiving a measured integrity value from a first device;
comparing the measured integrity value of the first device to an embedded integrity value associated with the integrity check processing module;
a control processing module operable to determine a level of trust for the first device based on the comparison.
13. The system of claim 12 , wherein the level of trust is one of a plurality of levels of trust that can be determined based on the comparison.
14. The system of claim 13 , wherein the plurality of levels of trust include a low level of trust, a medium level of trust, and a high level of trust.
15. The system of claim 14 , wherein determining the level of trust includes determining that the first device has a low level of trust in response to the measured integrity value not matching the embedded integrity value.
16. The system of claim 12 , wherein the control processing module is further operable to facilitate application of one of a plurality of communication policies associated with communicating with the first device based on the determined level of trust.
17. The system of claim 16 , wherein one of the plurality of policies includes restricting functions of the first device based on the determined level of trust.
18. The system of claim 16 , wherein one of the plurality of policies includes rejecting all communications with the first device based on the determined level of trust.
19. The system of claim 12 , wherein the control processing module is further operable to:
communicate with a backend server in response to the measured integrity value not matching the embedded integrity value;
receive an indication from the backend server an indication of the level of trust for the first device.
20. The system of claim 12 , wherein the control processing module is further operable to:
communicate with a backend server in response to the measured integrity value not matching the embedded integrity value;
receive one of a plurality of communication policies associated with communicating with the first device from the backend server.
21. The system of claim 12 , wherein the control processing module is further operable to:
request additional information from the first device in response to the measured integrity value not matching the embedded integrity value;
22. The system of claim 21 , wherein the additional information includes an identity of the first device and one or more intermediate measured integrity values.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US12/947,662 US20120047557A1 (en) | 2010-08-20 | 2010-11-16 | Method and System for Device Integrity Authentication |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US12/860,247 US9208318B2 (en) | 2010-08-20 | 2010-08-20 | Method and system for device integrity authentication |
US12/947,662 US20120047557A1 (en) | 2010-08-20 | 2010-11-16 | Method and System for Device Integrity Authentication |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US12/860,247 Continuation US9208318B2 (en) | 2010-08-20 | 2010-08-20 | Method and system for device integrity authentication |
Publications (1)
Publication Number | Publication Date |
---|---|
US20120047557A1 true US20120047557A1 (en) | 2012-02-23 |
Family
ID=44676352
Family Applications (3)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US12/860,247 Active 2032-08-04 US9208318B2 (en) | 2010-08-20 | 2010-08-20 | Method and system for device integrity authentication |
US12/947,662 Abandoned US20120047557A1 (en) | 2010-08-20 | 2010-11-16 | Method and System for Device Integrity Authentication |
US12/947,687 Abandoned US20120047578A1 (en) | 2010-08-20 | 2010-11-16 | Method and System for Device Integrity Authentication |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US12/860,247 Active 2032-08-04 US9208318B2 (en) | 2010-08-20 | 2010-08-20 | Method and system for device integrity authentication |
Family Applications After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US12/947,687 Abandoned US20120047578A1 (en) | 2010-08-20 | 2010-11-16 | Method and System for Device Integrity Authentication |
Country Status (3)
Country | Link |
---|---|
US (3) | US9208318B2 (en) |
JP (1) | JP5782914B2 (en) |
GB (1) | GB2482948A (en) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20130086635A1 (en) * | 2011-09-30 | 2013-04-04 | General Electric Company | System and method for communication in a network |
Families Citing this family (19)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8826437B2 (en) * | 2010-12-14 | 2014-09-02 | General Electric Company | Intelligent system and method for mitigating cyber attacks in critical systems through controlling latency of messages in a communications network |
US8656492B2 (en) * | 2011-05-16 | 2014-02-18 | General Electric Company | Systems, methods, and apparatus for network intrusion detection |
US9529777B2 (en) | 2011-10-28 | 2016-12-27 | Electronic Arts Inc. | User behavior analyzer |
US9082291B2 (en) * | 2012-12-17 | 2015-07-14 | Itron, Inc. | Virtual metering with partitioned metrology |
US9747786B2 (en) | 2012-12-17 | 2017-08-29 | Itron, Inc. | Virtual cluster meter (VCM) |
US9677907B2 (en) | 2013-03-14 | 2017-06-13 | Itron Inc | Intelligent receptacle |
US9503461B2 (en) * | 2014-12-30 | 2016-11-22 | International Business Machines Corporation | Authentication based on proximate devices |
US10427048B1 (en) | 2015-03-27 | 2019-10-01 | Electronic Arts Inc. | Secure anti-cheat system |
US9749310B2 (en) * | 2015-03-27 | 2017-08-29 | Intel Corporation | Technologies for authentication and single-sign-on using device security assertions |
US11179639B1 (en) | 2015-10-30 | 2021-11-23 | Electronic Arts Inc. | Fraud detection system |
US10459827B1 (en) | 2016-03-22 | 2019-10-29 | Electronic Arts Inc. | Machine-learning based anomaly detection for heterogenous data sources |
US9992018B1 (en) * | 2016-03-24 | 2018-06-05 | Electronic Arts Inc. | Generating cryptographic challenges to communication requests |
US10460320B1 (en) | 2016-08-10 | 2019-10-29 | Electronic Arts Inc. | Fraud detection in heterogeneous information networks |
US11212172B2 (en) | 2018-12-31 | 2021-12-28 | Itron, Inc. | Techniques for dynamically modifying operational behavior of network devices in a wireless network |
IL274840B1 (en) * | 2020-05-21 | 2024-03-01 | Google Llc | Verifying device and application integrity |
IL275947A (en) * | 2020-07-09 | 2022-02-01 | Google Llc | Anonymous event attestation |
KR102528678B1 (en) * | 2020-12-30 | 2023-05-08 | 한국전자통신연구원 | Apparatus and method for managing remote attestation |
DE102021101101A1 (en) | 2021-01-20 | 2022-07-21 | zereOS GmbH | Adapters and methods for affecting or diagnosing a device |
US11569995B2 (en) | 2021-03-15 | 2023-01-31 | Seagate Technology Llc | Provisional authentication of a new device added to an existing trust group |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20020083341A1 (en) * | 2000-12-27 | 2002-06-27 | Yehuda Feuerstein | Security component for a computing device |
US20060190606A1 (en) * | 2005-02-22 | 2006-08-24 | Kidaro Inc. | Data transfer security |
US20070143629A1 (en) * | 2004-11-29 | 2007-06-21 | Hardjono Thomas P | Method to verify the integrity of components on a trusted platform using integrity database services |
US20090055918A1 (en) * | 2007-08-23 | 2009-02-26 | Samsung Electronics Co., Ltd. | Method of mutually authenticating between software mobility device and local host and a method of forming input/output (i/o) channel |
US20090271844A1 (en) * | 2008-04-23 | 2009-10-29 | Samsung Electronics Co., Ltd. | Safe and efficient access control mechanisms for computing environments |
Family Cites Families (38)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP1030237A1 (en) | 1999-02-15 | 2000-08-23 | Hewlett-Packard Company | Trusted hardware device in a computer |
EP1055990A1 (en) | 1999-05-28 | 2000-11-29 | Hewlett-Packard Company | Event logging in a computing platform |
US6925566B1 (en) | 2000-07-07 | 2005-08-02 | Motorola, Inc. | Remote system integrity verification |
GB0020371D0 (en) | 2000-08-18 | 2000-10-04 | Hewlett Packard Co | Apparatus and method for establishing trust |
GB2372595A (en) | 2001-02-23 | 2002-08-28 | Hewlett Packard Co | Method of and apparatus for ascertaining the status of a data processing environment. |
US20030009687A1 (en) * | 2001-07-05 | 2003-01-09 | Ferchau Joerg U. | Method and apparatus for validating integrity of software |
US7216369B2 (en) | 2002-06-28 | 2007-05-08 | Intel Corporation | Trusted platform apparatus, system, and method |
SG176317A1 (en) | 2003-02-21 | 2011-12-29 | Research In Motion Ltd | System and method of multiple-level control of electronic devices |
JP3904534B2 (en) | 2003-05-30 | 2007-04-11 | 京セラコミュニケーションシステム株式会社 | Terminal status monitoring system and method |
US7437763B2 (en) | 2003-06-05 | 2008-10-14 | Microsoft Corporation | In-context security advisor in a computing environment |
GB2405232B (en) | 2003-08-21 | 2007-01-03 | Hewlett Packard Development Co | A method of and apparatus for controlling access to data |
JP4064914B2 (en) | 2003-12-02 | 2008-03-19 | インターナショナル・ビジネス・マシーンズ・コーポレーション | Information processing apparatus, server apparatus, method for information processing apparatus, method for server apparatus, and apparatus executable program |
JP2005180966A (en) | 2003-12-16 | 2005-07-07 | Toshiba Corp | Watt-hour meter equipped with program verification function |
JP4144880B2 (en) * | 2004-04-09 | 2008-09-03 | インターナショナル・ビジネス・マシーンズ・コーポレーション | Platform configuration measurement device, program and method, platform configuration authentication device, program and method, platform configuration certification device, program and method, and platform configuration disclosure device, program and method |
CN100358303C (en) * | 2005-02-28 | 2007-12-26 | 联想(北京)有限公司 | A method for monitoring apparatus being managed |
CN1703004B (en) | 2005-02-28 | 2010-08-25 | 联想(北京)有限公司 | Method for implementing network access authentication |
JP4099510B2 (en) * | 2005-06-03 | 2008-06-11 | 株式会社エヌ・ティ・ティ・ドコモ | Communication terminal device |
JP4437107B2 (en) | 2005-08-16 | 2010-03-24 | 日本電気株式会社 | Computer system |
WO2008024135A2 (en) | 2005-12-09 | 2008-02-28 | Signacert, Inc. | Method to verify the integrity of components on a trusted platform using integrity database services |
US20070239748A1 (en) | 2006-03-29 | 2007-10-11 | Smith Ned M | Management of reference data for platform verification |
KR101041543B1 (en) * | 2006-04-21 | 2011-06-17 | 인터디지탈 테크날러지 코포레이션 | Apparatus and methods for performing trusted computing integrity measurement reporting |
KR20120092675A (en) | 2006-05-05 | 2012-08-21 | 인터디지탈 테크날러지 코포레이션 | Digital rights management using trusted processing techniques |
US20080244758A1 (en) | 2007-03-30 | 2008-10-02 | Ravi Sahita | Systems and methods for secure association of hardward devices |
EP1990750A1 (en) | 2007-05-09 | 2008-11-12 | Nokia Siemens Networks Oy | Method and device for data processing and communication system comprising such device |
US7971059B2 (en) * | 2007-05-30 | 2011-06-28 | Bank Of America Corporation | Secure channel for image transmission |
CN100534036C (en) | 2007-08-01 | 2009-08-26 | 西安西电捷通无线网络通信有限公司 | A trusted network connection method based on three-element peer authentication |
CN100566251C (en) | 2007-08-01 | 2009-12-02 | 西安西电捷通无线网络通信有限公司 | A kind of trusted network connection method that strengthens fail safe |
CN100512313C (en) | 2007-08-08 | 2009-07-08 | 西安西电捷通无线网络通信有限公司 | A trusted network connection system for security enhancement |
US8782801B2 (en) | 2007-08-15 | 2014-07-15 | Samsung Electronics Co., Ltd. | Securing stored content for trusted hosts and safe computing environments |
US8752130B2 (en) * | 2007-12-21 | 2014-06-10 | Samsung Electronics Co., Ltd. | Trusted multi-stakeholder environment |
WO2009096181A2 (en) * | 2008-01-30 | 2009-08-06 | Panasonic Corporation | Secure boot with optional components method |
US8259949B2 (en) * | 2008-05-27 | 2012-09-04 | Intel Corporation | Methods and apparatus for protecting digital content |
AR073125A1 (en) * | 2008-08-25 | 2010-10-13 | Interdigital Patent Holdings | UNIVERSAL INTEGRATED CIRCUIT CARD THAT HAS A USER VIRTUAL IDENTIFICATION MODULE FUNCTION. |
US8103909B2 (en) * | 2008-09-15 | 2012-01-24 | Juniper Networks, Inc. | Automatic hardware-based recovery of a compromised computer |
US8161552B1 (en) * | 2009-09-23 | 2012-04-17 | Trend Micro, Inc. | White list creation in behavior monitoring system |
US8490179B2 (en) | 2009-10-27 | 2013-07-16 | Hewlett-Packard Development Company, L.P. | Computing platform |
US8826035B2 (en) * | 2009-12-23 | 2014-09-02 | Intel Corporation | Cumulative integrity check value (ICV) processor based memory content protection |
WO2011101538A1 (en) | 2010-02-16 | 2011-08-25 | Nokia Corporation | Method and apparatus to reset platform configuration register in mobile trusted module |
-
2010
- 2010-08-20 US US12/860,247 patent/US9208318B2/en active Active
- 2010-11-16 US US12/947,662 patent/US20120047557A1/en not_active Abandoned
- 2010-11-16 US US12/947,687 patent/US20120047578A1/en not_active Abandoned
-
2011
- 2011-07-28 GB GB1113026.7A patent/GB2482948A/en not_active Withdrawn
- 2011-08-19 JP JP2011179521A patent/JP5782914B2/en active Active
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20020083341A1 (en) * | 2000-12-27 | 2002-06-27 | Yehuda Feuerstein | Security component for a computing device |
US20070143629A1 (en) * | 2004-11-29 | 2007-06-21 | Hardjono Thomas P | Method to verify the integrity of components on a trusted platform using integrity database services |
US20060190606A1 (en) * | 2005-02-22 | 2006-08-24 | Kidaro Inc. | Data transfer security |
US20090055918A1 (en) * | 2007-08-23 | 2009-02-26 | Samsung Electronics Co., Ltd. | Method of mutually authenticating between software mobility device and local host and a method of forming input/output (i/o) channel |
US20090271844A1 (en) * | 2008-04-23 | 2009-10-29 | Samsung Electronics Co., Ltd. | Safe and efficient access control mechanisms for computing environments |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20130086635A1 (en) * | 2011-09-30 | 2013-04-04 | General Electric Company | System and method for communication in a network |
Also Published As
Publication number | Publication date |
---|---|
US20120047578A1 (en) | 2012-02-23 |
US20120047550A1 (en) | 2012-02-23 |
GB2482948A (en) | 2012-02-22 |
GB201113026D0 (en) | 2011-09-14 |
JP2012043438A (en) | 2012-03-01 |
JP5782914B2 (en) | 2015-09-24 |
US9208318B2 (en) | 2015-12-08 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20120047557A1 (en) | Method and System for Device Integrity Authentication | |
CN109791633B (en) | Static and dynamic device profile reputation using cloud-based machine learning | |
US9882912B2 (en) | System and method for providing authentication service for internet of things security | |
US10819728B2 (en) | Multi-tenant cloud security threat detection | |
US20130042124A1 (en) | Energy management device and power management system | |
US20100082984A1 (en) | Protocol-Independent Remote Attestation And Sealing | |
US10715547B2 (en) | Detecting “man-in-the-middle” attacks | |
JP2020506485A (en) | Method and computer for cryptographically protecting control communication and service access to an IT system, particularly in connection with diagnosis and configuration in an automation, control or monitoring system | |
US10469449B2 (en) | Port authentication control for access control and information security | |
US10462141B2 (en) | Network device information validation for access control and information security | |
CN110417567B (en) | Configuration method and device of Internet of things equipment | |
CN113468276A (en) | Trusted data acquisition method and device of on-chain prediction machine and electronic equipment | |
US11489829B1 (en) | Automatic account protection for compromised credentials | |
CN106650459B (en) | Safeguard the believable system and method for distributed memory system data | |
US9998495B2 (en) | Apparatus and method for verifying detection rule | |
Mugarza et al. | Safety and security concept for software updates on mixed-criticality systems | |
US11218297B1 (en) | Onboarding access to remote security control tools | |
US11392690B2 (en) | Security monitoring apparatus and method for vehicle network | |
JP7241766B2 (en) | Method and system for distribution verification and control of resource distribution network | |
JP5955165B2 (en) | Management apparatus, management method, and management program | |
US8756662B2 (en) | User authentication system and plant control system having user authentication system | |
KR20210028637A (en) | Extensible Certificate Management System Construction | |
CN117648100B (en) | Application deployment method, device, equipment and storage medium | |
US20240020360A1 (en) | Computer system, software tampering verification method, and non-transitory computer readable medium | |
CN116743458A (en) | Authentication management method, device, electronic equipment and storage medium |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: FUJITSU LIMITED, JAPAN Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:LEE, SUNG;CARDENAS, ALVARO A.;MASUOKA, RYUSUKE;REEL/FRAME:025379/0446 Effective date: 20100819 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |