US20160285840A1 - Goal-driven provisioning in iot systems - Google Patents
Goal-driven provisioning in iot systems Download PDFInfo
- Publication number
- US20160285840A1 US20160285840A1 US14/717,754 US201514717754A US2016285840A1 US 20160285840 A1 US20160285840 A1 US 20160285840A1 US 201514717754 A US201514717754 A US 201514717754A US 2016285840 A1 US2016285840 A1 US 2016285840A1
- Authority
- US
- United States
- Prior art keywords
- state
- iot
- shoal
- provisioning
- accordance
- 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.)
- Granted
Links
- 238000000034 method Methods 0.000 claims abstract description 14
- 238000004891 communication Methods 0.000 claims description 82
- 230000009471 action Effects 0.000 claims description 20
- 230000006870 function Effects 0.000 claims description 10
- 238000012163 sequencing technique Methods 0.000 claims description 4
- 230000036541 health Effects 0.000 claims description 3
- 238000012544 monitoring process Methods 0.000 claims description 3
- 230000000694 effects Effects 0.000 abstract description 7
- 230000007246 mechanism Effects 0.000 abstract description 2
- 230000008901 benefit Effects 0.000 description 6
- 238000010586 diagram Methods 0.000 description 5
- 238000005067 remediation Methods 0.000 description 5
- 230000007704 transition Effects 0.000 description 5
- 238000013459 approach Methods 0.000 description 3
- 238000011161 development Methods 0.000 description 3
- 238000012545 processing Methods 0.000 description 3
- 230000008859 change Effects 0.000 description 2
- 239000002826 coolant Substances 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 238000004519 manufacturing process Methods 0.000 description 2
- 230000001360 synchronised effect Effects 0.000 description 2
- 208000033748 Device issues Diseases 0.000 description 1
- 240000007643 Phytolacca americana Species 0.000 description 1
- 238000005267 amalgamation Methods 0.000 description 1
- 238000003491 array Methods 0.000 description 1
- 230000003190 augmentative effect Effects 0.000 description 1
- 238000013475 authorization Methods 0.000 description 1
- 230000006399 behavior Effects 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000009826 distribution Methods 0.000 description 1
- 125000000524 functional group Chemical group 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 238000002955 isolation Methods 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 239000000463 material Substances 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 230000003362 replicative effect Effects 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 230000000717 retained effect Effects 0.000 description 1
- 238000012552 review Methods 0.000 description 1
- 238000001228 spectrum Methods 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0893—Assignment of logical groups to network elements
-
- 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/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
- H04L63/062—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
-
- 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/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/31—User authentication
- G06F21/33—User authentication using certificates
- G06F21/335—User authentication using certificates for accessing specific resources, e.g. using Kerberos tickets
-
- 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/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
- G06F21/71—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information
- G06F21/72—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information in cryptographic circuits
-
- 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/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
- G06F21/71—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information
- G06F21/74—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information operating in dual or compartmented mode, i.e. at least one secure mode
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0803—Configuration setting
- H04L41/0806—Configuration setting for initial configuration or provisioning, e.g. plug-and-play
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
- H04L63/065—Network architectures or network communication protocols for network security for supporting key management in a packet data network for group communications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0876—Network architectures or network communication protocols for network security for authentication of entities based on the identity of the terminal or configuration, e.g. MAC address, hardware or software configuration or device fingerprint
-
- 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/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
- H04L63/104—Grouping of entities
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/30—Security of mobile devices; Security of mobile applications
- H04W12/35—Protecting application or service provisioning, e.g. securing SIM application provisioning
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/70—Services for machine-to-machine communication [M2M] or machine type communication [MTC]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/2115—Third party
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
- H04L2463/041—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 using an encryption or decryption engine integrated in transmitted data
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
Definitions
- Embodiments described herein generally relate to computer network operations. More particularly, embodiments described herein relate to provisioning devices that are organized into self-directed functional groups.
- IoT Internet of Things
- the phrase Internet of Things (IoT) refers to physical objects, devices or “things” embedded with electronics, software and the ability to connect to the Internet.
- the connectivity permits the implementation of systems that monitor and control an activity.
- multiple pumps in a nuclear power plant may be controlled (turned on/off or throttled) based on a number of factors such as the desired power level, coolant temperature, and the operation of other pumps within the coolant loop.
- sensors e.g., a light sensor
- actuators e.g., a light switch
- collections of sensors and actuators may be designed to function as a unit, where inter-device communication is operationally beneficial or necessary.
- the Internet in contrast, was designed to facilitate host-to-host communication.
- traditional approaches to provisioning involve the use of trusted third parties such as manageability services, key management services and access management services.
- Recent trends in cloud computing have exacerbated this shift toward centralizing many security provisioning services.
- Centralized services represent a single point of failure for safety critical cyber-physical systems (think pump controllers in a nuclear power plant and health monitoring systems in a hospital).
- Centralized security provisioning services also imply a trust relationship is required between IoT devices and the central entity. Such centralization of trust represents a fallacious expectation that such an entity can operate without conflicts of interest and without increasing the device's attack surface exposure. Such assumptions may not be appropriate for many IoT systems.
- FIG. 1 shows, in block diagram form, an IoT system in accordance with one embodiment.
- FIG. 2 shows, in block diagram form, an IoT device in accordance with one embodiment.
- FIG. 3 shows, in block diagram form, an illustrative IoT system in accordance with one embodiment.
- FIG. 4 shows, in block diagram form, an illustrative IoT system in accordance with another embodiment.
- This disclosure pertains to systems, methods, and computer readable media to organize and operate IoT devices in a novel and non-obvious manner.
- techniques are disclosed for provisioning IoT devices in accordance with a state machine model. More particularly, collections of such IoT devices may be organized into enclaves, groups or “shoals” that operate as autonomous or semi-autonomous groups of devices functioning as a collective having a common objective or mission. IoT devices participating in a shoal may be provisioned with shoal-specific context information as part of their device-specific provisioning activity.
- a shoal context object can include a current state variable and a target next state variable.
- the shoal's target next state variable establishes a goal (e.g., for provisioning activity) without dictating how the individual shoal members (IoT device) are to achieve that goal.
- This mechanism may be used to drive a shoal's separate devices through their individual provisioning state machines until theshoal itself is made operational.
- IoT system 100 in accordance with one embodiment includes a number of IoT devices 105 A- 105 F and 105 G through 105 N grouped into shoal- 1 110 and shoal- 2 115 , router/gateway 120 , network 125 , key management server 130 , access control management server 135 with management servers 130 and 135 identified collectively as third party service providers 140 .
- each device may be as simple or as complex as its individual function requires; while only a limited number of devices have been shown, each shoal may include as many or as few devices as necessary to perform its designated function e.g., the control of a series of pumps in a nuclear power plant or a single light); shoal- 1 110 has been shown overlapping shoal- 2 115 to illustrate that a single device may belong to more than one shoal, and should not be taken as limiting a device to 2 shoals; router/gateway 120 may be as simple or complex as needed (e.g., including both wireless and wired elements); network 125 represents 1 or more separate networks each of which may take any form including, but not limited to, a Local Area Network (LAN) or a Wide Area Network (WAN) such as the Internet, any of which may use any desired technology (wired, wireless or a combination thereof) and communication protocol such as the Transmission Control Protocol (TCP) or the Point-to-Point Protocol (PPP); and third party service provides 140 represent as many
- Illustrative IoT devices that may benefit from this disclosure include, but are not limited to, wearable devices (e.g., battery powered device), media players (e.g., for music and movies), home or factory automation (devices needing low latency communication for product interoperability), and smart devices (e.g., direct network connection that are tightly coupled to a service).
- wearable devices e.g., battery powered device
- media players e.g., for music and movies
- home or factory automation devices needing low latency communication for product interoperability
- smart devices e.g., direct network connection that are tightly coupled to a service.
- IoT device 105 A in accordance with one embodiment includes cryptographic element 200 , processor 205 , memory 210 , support circuitry or module 215 , and device-specific elements 220 .
- Cryptographic element 200 may be implemented in any appropriate fashion and, in one embodiment, may be a single tamper-resistant package that includes all of the necessary cryptographic processing capability necessary for device 105 A to join a communications network and operate with other IoT devices within a secure environment. In other embodiments a secure operating environment may not need to be affirmatively established and so cryptographic element 200 may not be necessary (e.g., a shoal may operate in a physically secure environment such as that provided by an isolated network).
- Processor 205 may be any one or more processing elements (programmable or hardwired) and, in many IoT devices, is often resource constrained (e.g., having limited computational capability, memory, and access to power).
- Memory 210 may include memory cache, read-only memory (ROM), and/or random access memory (RAM).
- Support module 215 may include whatever additional components are needed to enable cryptographic element 200 , processor 205 and memory 210 to interact with external components (e.g., one or more communication ports) and device-specific elements 220 to fulfill the purpose of the device such as, for example, sensors and/or actuators.
- IoT device 105 A may at time of manufacture, or later, be loaded with the necessary cryptologic keys and certificates and at least one state machine in accordance with this disclosure.
- cryptologic element 200 may be loaded with a base set of keys and certificates when manufactured, while device 105 A (e.g., memory 210 ) may be loaded by an OEM with one or more state machines.
- exemplary IoT system 300 includes IoT device 105 A (including illustrative state machine 305 ) and remediation service 310 .
- IoT device 105 A including illustrative state machine 305
- remediation service 310 remediation service 310 .
- the state machine may be represented by firmware programmed in a specified manner.
- the state machine may be represented in user-level program code.
- the state machine may be represented by a combination of firmware and user-level program code.
- the state machine may be represented by a combination of software and hardware.
- the state machine may be embodied directly in hardware (e.g., via field-programmable gate arrays).
- device-specific and shoal-specific state information 315 and 320 respectively. This information may, for example, be retained in memory 210 (see FIG. 2 ).
- Device-specific state information 315 can be that used by conventional IoT devices augmented by any additional state information needed to support the device's state machine such as, for example, a current state variable (‘current.dstate’) and a target next state variable (‘next.dstate’).
- Shoal-specific state information 320 can include a shoal state object that has at least 2 state variables. One to indicate the shoal's current state (‘current.sstate’), and the other to indicate the shoal's target next state (‘next.sstate’).
- Table 1 enumerates the provisioning states that may be entered into during a device's progression from a primitive state (e.g., OWNED) to a fully functional state (e.g., OPERATIONAL) and corresponds to illustrative state machine 305 .
- Table 2 describes the actions taken when transitioning from one state to a next state in state machine 305 .
- the states identified in Table 1 and the actions identified in Table 2 constitute an illustrative state model only.
- An IoT device's actual state machine in accordance with this disclosure may have more or fewer states than those shown.
- the structure of state machine 305 has been made simple for presentational purposes.
- An actual state machine may be as simple or complex as the device's task requires.
- Device may include, for example, a base set of cryptographic keys, a PIN, or physical switch that can be used to place the device in a mode where it is accepting of a “take owner” protocol.
- OWNED Control and ownership resides in a entity other than the manufacturer.
- the new owner can provide or generate a secret (e.g., a symmetric key) as proof that device ownership has been taken by the new owner.
- the ‘secret’ may be used to establish a bootstrap service (key, URL) that instructs the device where to go when it needs to be bootstrap provisioned, This may be done so that the owner's pre-shared key (PSK), initially used to provision the bootstrap server, does not need to be frequently used. This, in turn, allows the owner's PSK values to be archived in a safe location. These keys need only be used when the device needs to be wiped clean of all provisioning data, but where retaking ownership is not desired. This step can be done down-the-wire or over-the-air.
- PROVISIONED Device is provisioned in accordance with the new owner's designated bootstrap service. REGISTERED Secure communications has been established between pairs of loT devices.
- ENROLLED Device's role within a shoal established e.g., administrator, synchronization broker
- provisioning all of the devices in a shoal and creating role privileges that all the devices recognize and can validate may be part of the credential structure on each device.
- CONTROLLED An loT device can have a set of resources that define its behavior and nature. Resource access, in turn, may be restricted using an access control list (ACL). In this state a device is provisioned with all ACLs it needs to perform its designated function (i.e., so that it may be “controlled”).
- ACL access control list
- CONFIGURED Devices with resources may be ready to perform some duty, but would not do anything without another device (a client) asking it to do so. Since client devices may be headless (lacking a graphical user-interface) and autonomous, there needs to be a way to tell a server what to do. In this state, all necessary script(s) and/or control logic needed to permit the device (acting as a client) to trigger an action in another device (acting as a server) have been obtained. OPERATIONAL Device is fully provisioned and ready to begin performing its designated activity as part of a shoal.
- UN-OWNED ⁇ Device asserts the “take-owner” protocol to shift ownership to a OWNED new owner.
- OWNED ⁇ Device uses bootstrap key to access the designated bootstrap PROVISIONED service to bootstrap provision itself.
- PROVISIONED ⁇ Pair-wise symmetric keys are created, provisioned and used to REGISTERED establish secure communications between pairs of loT devices so that they may function as a cohesive unit, Once complete, the devices may be said to be “registered” with one another.
- REGISTERED ⁇ Device asserts a role within the shoal to other shoal members ENROLLED (e.g., administrator or synchronization broker) so that it may gain access to functionality and resources that require privilege.
- ENROLLED e.g., administrator or synchronization broker
- the ability to broadcast or multi-cast to other devices requires a symmetric key that is shared by all the other devices being communicated with. (Provisioning all of the devices in a shoal and creating role privileges that all the devices recognize and can validate may be part of the credential structure of each device.) ENROLLED ⁇ During this transition a device's ACL policy and provisioning may CONTROLLED be configured (this is what allows a device to be controlled). Devices that don't have any ACLs may default to no-access. Such a policy necessarily needs to allow interaction with a provisioning service that supplies the ACLs.
- CONTROLLED ⁇ Device obtains the necessary script(s) and/or control logic that CONFIGURED permits it to ask another device (acting as a server) to do some task. This establishes the highest level of configuration without the device actually doing something.
- CONFIGURED ⁇ Device issues or receives a trigger, broadcast, multicast or timer to OPERATIONAL signal all the shoal's devices that they are to begin executing their programmed task. (Triggering may not need to be a synchronized event, but the state model approach described herein allows this to occur if appropriate.)
- remediation service 310 may be notified.
- control from remediation server 310 is returned to device 105 ; the specific state can depend upon which state failed.
- control may be returned to the state that failed.
- control may be returned to the last successfully traversed state.
- control may be returned to a known/specified error-return state (not shown).
- device 105 A knows its owner but is not otherwise provisioned e.g., it is in the OWNED state. In practice this may be accomplished using an anonymous identification key (AIK) for which some local service vets. There can then be a challenge/response sequence wherein the server (“owner”) authenticates the client (IoT device) using this key only during the “get acquainted” phase, the public key may be used to encrypt a random number or string that can become a shared secret. There are also network protocols, such as the Extensible Authentication Protocol (EAP), that facilitate this exchange in a simple and efficient manner.
- EAP Extensible Authentication Protocol
- EAP EAP
- DHCP Dynamic Host Configuration Protocol
- PKI Public Key infrastructure
- shoal- 1 110 includes IoT devices 105 A-E (see FIG. 1 ) and shoal context 400 which is shared across all shoal devices.
- the shoal's shared context includes the shoal's current state (current.sstate), its target next state (next.sstate) and identification of a synchronization broker (i.e., a device designated to replicate shoal state 400 to other shoal members).
- a synchronization broker i.e., a device designated to replicate shoal state 400 to other shoal members.
- example shoal shared context 400 illustrates the types of information that may be used to track a shoal's state.
- shoal controller there isn't necessarily a dominant shoal controller, though one or more devices may be nominated as a synchronization broker for replicating shoal context 400 (at a minimum). Additional devices may also be nominated as shoal service entities supporting security, management and access needs. (The creation of role privileges that all of a shoal's devices recognize and can validate may be part of the credential structure on each device.) Shoal devices may also include cloud and enterprise services, but isolation technologies may need to be used to reasonably ensure the cloud hosted entity is prevented from introducing non-shoal devices/controllers into the shoal.
- the shoal name itself may be assigned by a trusted naming authority such as an Internet Domain Naming Service (DNS) also known as DANE DNS (Domain Name System)-Based Authentication of Named Entities.
- DNS Internet Domain Naming Service
- DANE DNS Domain Name System
- a system in accordance with this disclosure may accept shoal names from a DANE or other naming authority.
- the Shoal may embed the trust anchor of a DANE authority as part of the shoal resource (e.g. External Cred).
- the shoal name my be given to a peer shoal or organization network hosting a key distribution service such as Kerberos where the tickets assigned contain the DANE assigned name as the Kerberos ‘realm’ name.
- each device in shoal- 1 110 is in a different state.
- the shoal's current state 405 may be an amalgamation of the respective shoal device states.
- a reasonable methodology for determining the shoal's current state is to take the most primitive of the shoal's device's state. Comparing FIG. 4 to FIG. 3 or Table 1, the most primitive device state is “OWNED”.
- the shoal's next state value 410 is designed to drive all devices to the OPERATIONAL state which, in the example of FIG. 3 and Table 1, is the state in which the collective function of the shoal may be manifest. Though each device is at a different provisioning state, this does not necessarily mean the devices are not connected and cannot perform operations. They can perform provisioning operations.
- Shoal state variables may be maintained locally at each device so that each device may independently function to acquire provisioning from accessible/neighboring devices and services.
- Shoal state variables e.g., current.sstate and next.sstate
- Shoal state variables may be synchronized across each shoal member so each knows its own state and the shoal's state.
- synchronization may be achieved using a group multi-cast or publish-subscribe relays such as the MQTT (formerly Message Queue Telemetry Transport) and Extensible Messaging and Presence Protocol (XMPP) message brokers.
- MQTT formerly Message Queue Telemetry Transport
- XMPP Extensible Messaging and Presence Protocol
- One benefit of a state machine based approach to device provisioning is that it can free a system's administrator from micro-managing each device's provisioning operations.
- each device's state machine defines what it may do (but not necessarily how)
- different devices may perform the same function in different ways—each according to their own operational capabilities. This, in turn, can improve the operational efficiency of a shoal. This same capability permits newer devices to be easily integrated into existing IoT systems (shoals).
- benefits of the disclosed techniques include, but are not limited to use of a group context structure containing goal-oriented provisioning state variables; use of a group context structure that is defined across shoal members; IoT devices with provisioning state variables; use of Trusted Execution Environment (TEE) protocols to permit the protected execution of a shoal entity; use of one (or more) shoal member devices to assist in the provisioning of a neighbor shoal member device; use of a shoal access control structure/policy to enforce access of shoal member resources by other shoal devices and non-shoal devices; use of an attestation method such as, for example, the Enhanced Privacy ID (EPID) and Sigma key exchange protocols to establish a provisioning channel between one IoT device and a sibling IoT device authorized to share provisioning information;
- EEE Trusted Execution Environment
- Example 1 is an Internet of Things (IoT) device, comprising: device hardware configured to function in accordance with a type of device; IoT hardware including: a network communication circuit configured to connect to a network communication medium, memory communicatively coupled to the network communication circuit, and a processor operatively coupled to the device hardware, the network communication circuit and the memory, the memory storing instructions that when executed cause the processor to: employ a provisioning state machine corresponding to the type of device and IoT hardware, wherein the provisioning state machine includes a plurality of states, the final state being an operational state, establish a shoal-specific state information in the memory in accordance with the provisioning state machine, establish an IoT device-specific state information in the memory in accordance with the provisioning state machine, establish communication through the network communication circuit with one or more additional IoT devices, wherein the IoT device and each of the one or more additional IoT devices belong to a shoal of IoT devices, determine, based on the established communication, a state of the shoal
- Example 2 the subject matter of Example 1 can optionally include wherein the type of device comprises a pump controller.
- Example 3 the subject matter of Example 1 can optionally include wherein the network communication medium comprises a wireless network communication medium.
- Example 4 the subject matter of any one of Examples 1-3 can optionally include wherein the IoT hardware further includes a cryptographic element communicatively coupled to the processor.
- Example 5 the subject matter of Example 4 can optionally include further comprising instructions stored in the memory that, when executed, cause the processor to use the cryptographic element to establish secure communication with the one or more additional IoT devices.
- Example 6 the subject matter of any one of Examples 1-3 can optionally include wherein the instructions to cause the processor to sequence through the plurality of states comprise instructions to cause the processor to use a mismatch between the shoal state and the IoT device state to initiate action to move to a new state in accordance with the provisioning state machine.
- Example 7 the subject matter of any one of Examples 1-3 can optionally include wherein each state in the provisioning state machine has actions associated with provisioning the IoT device.
- Example 8 is an Internet of Things (IoT) operational method, comprising: loading an IoT device with a provisioning state machine control software, wherein the provisioning state machine control software corresponds to the type of IoT device and includes a plurality of states, the final state being an operational state; establishing a shoal-specific state information and a device-specific state information in a memory of the IoT device in accordance with the provisioning state machine; establishing communication through a network communication circuit of the IoT device with one or more additional IoT devices, wherein the IoT device and each of the one or more additional IoT devices belong to a shoal of IoT devices; determining, based on the established communication, a state of the shoal and recording the same in the shoal-specific state information; determining a state of the IoT device and recording the same in the IoT device-specific state information; and sequencing through the plurality of states based on a combination of the shoal state and the IoT device state until the I
- Example 9 the subject matter of Example 8 can optionally include wherein the type of device comprises a health monitoring system device.
- Example 10 the subject matter of Example 8 can optionally include wherein the network communication medium comprises a wireless network communication medium.
- Example 11 the subject matter of any one of Examples 8-10 can optionally include further comprising using a cryptographic element of the IoT device to establish secure communication with at least one of the one or more additional IoT devices.
- Example 12 the subject matter of any one of Examples 8-10 can optionally include wherein sequencing through the plurality of states comprises using a mismatch between the shoal state and the IoT device state to initiate action to move to a new state in accordance with the provisioning state machine.
- Example 13 the subject matter of any one of Examples 8-10 can optionally include wherein each state in the provisioning state machine has actions associated with provisioning the IoT device.
- Example 14 is a program storage device comprising instructions stored thereon to cause one or more processors in an Internet of Things (IoT) device to: activate a provisioning state machine corresponding to the IoT device's type, wherein the provisioning state machine includes a plurality of states, the final state being an operational state; establish a shoal-specific state information in a memory of the IoT device in accordance with the provisioning state machine: establish an IoT device-specific state information in the memory in accordance with the provisioning state machine; establish communication through a network communication circuit with one or more additional IoT devices, wherein the IoT device and each of the one or more additional IoT devices belong to a shoal of IoT devices; determine, based on the established communication, a state of the shoal and record the same in the shoal-specific state information; determine a state of the IoT device and record the same in the IoT device-specific state information; and sequence through the plurality of states based on a combination of the shoal
- Example 15 the subject matter of Example 14 can optionally include wherein the instructions to establish communication through a network communication circuit comprise instructions to establish communication through a wireless network communication circuit.
- Example 16 the subject matter of any one of Examples 14-15 can optionally include wherein the instructions to establish communication through a network communication circuit comprise instructions to establish secure communication through a network communication circuit using a cryptographic element of the IoT device.
- Example 17 the subject matter of any one of Examples 14-15 can optionally include wherein the instructions to cause the processor to sequence through the plurality of states comprise instructions to cause the processor to use a mismatch between the shoal state and the IoT device state to initiate action to move to a new state in accordance with the provisioning state machine.
- Example 18 the subject matter of Example 14 can optionally include wherein each state in the provisioning state machine has actions associated with provisioning the IoT device.
- Example 19 is an Internet of Things (IoT) device, comprising: a processor; a memory operatively coupled to the processor, the memory storing instructions that when executed cause the processor to: activate a provisioning state machine corresponding to the IoT device's type, wherein the provisioning state machine includes a plurality of states, the final state being an operational state; establish a shoal-specific state information in a memory of the IoT device in accordance with the provisioning state machine; establish an IoT device-specific state information in the memory in accordance with the provisioning state machine; establish communication through a network communication circuit with one or more additional IoT devices, wherein the IoT device and each of the one or more additional IoT devices belong to a shoal of IoT devices; determine, based on the established communication, a state of the shoal and record the same in the shoal-specific state information; determine a state of the IoT device and record the same in the IoT device-specific state information; and sequence through the plurality of states
- Example 20 the subject matter of Example 19 can optionally include wherein the instructions to establish communication through a network communication circuit comprise instructions to establish communication through a wireless network communication circuit.
- Example 21 the subject matter of any one of Examples 19-20 can optionally include wherein the instructions to establish communication through a network communication circuit comprise instructions to establish secure communication through a network communication circuit using a cryptographic element of the IoT device.
- Example 22 the subject matter of any one of Examples 19-20 can optionally include wherein the instructions to cause the processor to sequence through the plurality of states comprise instructions to cause the processor to use a mismatch between the shoal state and the IoT device state to initiate action to move to a new state in accordance with the provisioning state machine.
- Example 23 the subject matter of Example 19 can optionally include wherein each state in the provisioning state machine has actions associated with provisioning the IoT device.
- each shoal member may share credentials with only some (but not all) other shoal members. Further, each shoal may have multiple synchronization members.
- a single shoal member may act as the synchronization broker for an entire shoal.
- a different synchronization broker may be used for each shoal/group attribute (e.g., calculate shoal state, keep group membership, and credential management).
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Software Systems (AREA)
- General Physics & Mathematics (AREA)
- Computing Systems (AREA)
- Mathematical Physics (AREA)
- Health & Medical Sciences (AREA)
- General Health & Medical Sciences (AREA)
- Medical Informatics (AREA)
- Telephonic Communication Services (AREA)
- Power Engineering (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
Description
- Embodiments described herein generally relate to computer network operations. More particularly, embodiments described herein relate to provisioning devices that are organized into self-directed functional groups.
- The phrase Internet of Things (IoT) refers to physical objects, devices or “things” embedded with electronics, software and the ability to connect to the Internet. The connectivity permits the implementation of systems that monitor and control an activity. By way of example, multiple pumps in a nuclear power plant may be controlled (turned on/off or throttled) based on a number of factors such as the desired power level, coolant temperature, and the operation of other pumps within the coolant loop. Thus, not only can single sensors (e.g., a light sensor) or actuators (e.g., a light switch) be controlled in this way, but collections of sensors and actuators may be designed to function as a unit, where inter-device communication is operationally beneficial or necessary.
- The Internet, in contrast, was designed to facilitate host-to-host communication. Within such an environment, traditional approaches to provisioning involve the use of trusted third parties such as manageability services, key management services and access management services. Recent trends in cloud computing have exacerbated this shift toward centralizing many security provisioning services. Centralized services represent a single point of failure for safety critical cyber-physical systems (think pump controllers in a nuclear power plant and health monitoring systems in a hospital). Centralized security provisioning services also imply a trust relationship is required between IoT devices and the central entity. Such centralization of trust represents a fallacious expectation that such an entity can operate without conflicts of interest and without increasing the device's attack surface exposure. Such assumptions may not be appropriate for many IoT systems.
-
FIG. 1 shows, in block diagram form, an IoT system in accordance with one embodiment. -
FIG. 2 shows, in block diagram form, an IoT device in accordance with one embodiment. -
FIG. 3 shows, in block diagram form, an illustrative IoT system in accordance with one embodiment. -
FIG. 4 shows, in block diagram form, an illustrative IoT system in accordance with another embodiment. - This disclosure pertains to systems, methods, and computer readable media to organize and operate IoT devices in a novel and non-obvious manner. In general, techniques are disclosed for provisioning IoT devices in accordance with a state machine model. More particularly, collections of such IoT devices may be organized into enclaves, groups or “shoals” that operate as autonomous or semi-autonomous groups of devices functioning as a collective having a common objective or mission. IoT devices participating in a shoal may be provisioned with shoal-specific context information as part of their device-specific provisioning activity. By way of example, a shoal context object can include a current state variable and a target next state variable. The shoal's target next state variable establishes a goal (e.g., for provisioning activity) without dictating how the individual shoal members (IoT device) are to achieve that goal. This mechanism may be used to drive a shoal's separate devices through their individual provisioning state machines until theshoal itself is made operational.
- In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the disclosed concepts. As part of this description, some of this disclosure's drawings represent structures and devices in block diagram form in order to avoid obscuring the novel aspects of the disclosed concepts. In the interest of clarity, not all features of an actual implementation are described. Moreover, the language used in this disclosure has been principally selected for readability and instructional purposes, and may not have been selected to delineate or circumscribe the inventive subject matter, resort to the claims being necessary to determine such inventive subject matter. Reference in this disclosure to “one embodiment” or to “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the disclosed subject matter, and multiple references to “one embodiment” or “an embodiment” should not be understood as necessarily all referring to the same embodiment.
- It will be appreciated that in the development of any actual implementation (as in any software and/or hardware development project), numerous decisions must be made to achieve the developers' specific goals (e.g., compliance with system- and business-related constraints), and that these goals may vary from one implementation to another. It will also be appreciated that such development efforts might be complex and time-consuming, but would nevertheless be a routine undertaking for those of ordinary skill in the design and implementation of IoT device processing systems having the benefit of this disclosure.
- Referring to
FIG. 1 , IoTsystem 100 in accordance with one embodiment includes a number ofIoT devices 105A-105F and 105G through 105N grouped into shoal-1 110 and shoal-2 115, router/gateway 120,network 125,key management server 130, accesscontrol management server 135 withmanagement servers party service providers 140. It should be understood that: each device may be as simple or as complex as its individual function requires; while only a limited number of devices have been shown, each shoal may include as many or as few devices as necessary to perform its designated function e.g., the control of a series of pumps in a nuclear power plant or a single light); shoal-1 110 has been shown overlapping shoal-2 115 to illustrate that a single device may belong to more than one shoal, and should not be taken as limiting a device to 2 shoals; router/gateway 120 may be as simple or complex as needed (e.g., including both wireless and wired elements);network 125 represents 1 or more separate networks each of which may take any form including, but not limited to, a Local Area Network (LAN) or a Wide Area Network (WAN) such as the Internet, any of which may use any desired technology (wired, wireless or a combination thereof) and communication protocol such as the Transmission Control Protocol (TCP) or the Point-to-Point Protocol (PPP); and third party service provides 140 represent as many or as few service providers as necessary to support devices 105 provisioning operations—further, a single physical device may provide multiple services. Illustrative IoT devices that may benefit from this disclosure include, but are not limited to, wearable devices (e.g., battery powered device), media players (e.g., for music and movies), home or factory automation (devices needing low latency communication for product interoperability), and smart devices (e.g., direct network connection that are tightly coupled to a service). - Referring now to
FIG. 2 , IoTdevice 105A in accordance with one embodiment includescryptographic element 200,processor 205,memory 210, support circuitry ormodule 215, and device-specific elements 220.Cryptographic element 200 may be implemented in any appropriate fashion and, in one embodiment, may be a single tamper-resistant package that includes all of the necessary cryptographic processing capability necessary fordevice 105A to join a communications network and operate with other IoT devices within a secure environment. In other embodiments a secure operating environment may not need to be affirmatively established and socryptographic element 200 may not be necessary (e.g., a shoal may operate in a physically secure environment such as that provided by an isolated network).Processor 205 may be any one or more processing elements (programmable or hardwired) and, in many IoT devices, is often resource constrained (e.g., having limited computational capability, memory, and access to power).Memory 210 may include memory cache, read-only memory (ROM), and/or random access memory (RAM).Support module 215 may include whatever additional components are needed to enablecryptographic element 200,processor 205 andmemory 210 to interact with external components (e.g., one or more communication ports) and device-specific elements 220 to fulfill the purpose of the device such as, for example, sensors and/or actuators.IoT device 105A may at time of manufacture, or later, be loaded with the necessary cryptologic keys and certificates and at least one state machine in accordance with this disclosure. In one scenario,cryptologic element 200 may be loaded with a base set of keys and certificates when manufactured, whiledevice 105A (e.g., memory 210) may be loaded by an OEM with one or more state machines. - Referring to
FIG. 3 ,exemplary IoT system 300 includesIoT device 105A (including illustrative state machine 305) andremediation service 310. It will be understood that when a device is said to “have” or “include” a state machine, it means that some representation of the state machine has been delivered to or incorporated in the device. In one embodiment, the state machine may be represented by firmware programmed in a specified manner. In another embodiment, the state machine may be represented in user-level program code. In yet another embodiment, the state machine may be represented by a combination of firmware and user-level program code. In still another embodiment, the state machine may be represented by a combination of software and hardware. In yet another embodiment, the state machine may be embodied directly in hardware (e.g., via field-programmable gate arrays). Also shown inFIG. 3 are device-specific and shoal-specific state information, 315 and 320 respectively. This information may, for example, be retained in memory 210 (seeFIG. 2 ). Device-specific state information 315 can be that used by conventional IoT devices augmented by any additional state information needed to support the device's state machine such as, for example, a current state variable (‘current.dstate’) and a target next state variable (‘next.dstate’). Shoal-specific state information 320 can include a shoal state object that has at least 2 state variables. One to indicate the shoal's current state (‘current.sstate’), and the other to indicate the shoal's target next state (‘next.sstate’). - Table 1 enumerates the provisioning states that may be entered into during a device's progression from a primitive state (e.g., OWNED) to a fully functional state (e.g., OPERATIONAL) and corresponds to
illustrative state machine 305. Table 2 describes the actions taken when transitioning from one state to a next state instate machine 305. The states identified in Table 1 and the actions identified in Table 2 constitute an illustrative state model only. An IoT device's actual state machine in accordance with this disclosure may have more or fewer states than those shown. In addition, the structure ofstate machine 305 has been made simple for presentational purposes. An actual state machine may be as simple or complex as the device's task requires. -
TABLE 1 Example State Machine States State Status UN-OWNED As built or provided by manufacturer. Device may include, for example, a base set of cryptographic keys, a PIN, or physical switch that can be used to place the device in a mode where it is accepting of a “take owner” protocol. OWNED Control and ownership resides in a entity other than the manufacturer. The new owner can provide or generate a secret (e.g., a symmetric key) as proof that device ownership has been taken by the new owner. The ‘secret’ may be used to establish a bootstrap service (key, URL) that instructs the device where to go when it needs to be bootstrap provisioned, This may be done so that the owner's pre-shared key (PSK), initially used to provision the bootstrap server, does not need to be frequently used. This, in turn, allows the owner's PSK values to be archived in a safe location. These keys need only be used when the device needs to be wiped clean of all provisioning data, but where retaking ownership is not desired. This step can be done down-the-wire or over-the-air. PROVISIONED Device is provisioned in accordance with the new owner's designated bootstrap service. REGISTERED Secure communications has been established between pairs of loT devices. ENROLLED Device's role within a shoal established (e.g., administrator, synchronization broker) so that all other shoal devices recognize the same. (Provisioning all of the devices in a shoal and creating role privileges that all the devices recognize and can validate may be part of the credential structure on each device.) CONTROLLED An loT device can have a set of resources that define its behavior and nature. Resource access, in turn, may be restricted using an access control list (ACL). In this state a device is provisioned with all ACLs it needs to perform its designated function (i.e., so that it may be “controlled”). CONFIGURED Devices with resources (a server) may be ready to perform some duty, but would not do anything without another device (a client) asking it to do so. Since client devices may be headless (lacking a graphical user-interface) and autonomous, there needs to be a way to tell a server what to do. In this state, all necessary script(s) and/or control logic needed to permit the device (acting as a client) to trigger an action in another device (acting as a server) have been obtained. OPERATIONAL Device is fully provisioned and ready to begin performing its designated activity as part of a shoal. -
TABLE 2 Example State Machine State Transitions State Transition Action UN-OWNED → Device asserts the “take-owner” protocol to shift ownership to a OWNED new owner. OWNED → Device uses bootstrap key to access the designated bootstrap PROVISIONED service to bootstrap provision itself. PROVISIONED → Pair-wise symmetric keys are created, provisioned and used to REGISTERED establish secure communications between pairs of loT devices so that they may function as a cohesive unit, Once complete, the devices may be said to be “registered” with one another. REGISTERED → Device asserts a role within the shoal to other shoal members ENROLLED (e.g., administrator or synchronization broker) so that it may gain access to functionality and resources that require privilege. For example, the ability to broadcast or multi-cast to other devices requires a symmetric key that is shared by all the other devices being communicated with. (Provisioning all of the devices in a shoal and creating role privileges that all the devices recognize and can validate may be part of the credential structure of each device.) ENROLLED → During this transition a device's ACL policy and provisioning may CONTROLLED be configured (this is what allows a device to be controlled). Devices that don't have any ACLs may default to no-access. Such a policy necessarily needs to allow interaction with a provisioning service that supplies the ACLs. CONTROLLED → Device obtains the necessary script(s) and/or control logic that CONFIGURED permits it to ask another device (acting as a server) to do some task. This establishes the highest level of configuration without the device actually doing something. CONFIGURED → Device issues or receives a trigger, broadcast, multicast or timer to OPERATIONAL signal all the shoal's devices that they are to begin executing their programmed task. (Triggering may not need to be a synchronized event, but the state model approach described herein allows this to occur if appropriate.) - Returning to
FIG. 3 , if actions in accordance with any given state fail,remediation service 310 may be notified. In the embodiment ofFIG. 3 , control fromremediation server 310 is returned to device 105; the specific state can depend upon which state failed. In one embodiment, control may be returned to the state that failed. In another embodiment, control may be returned to the last successfully traversed state. In still another embodiment, control may be returned to a known/specified error-return state (not shown). - A review of
FIG. 3 and Tables 1 and 2 indicate that only the UN_OWNED to OWNED state transition is not self-starting. That is,device 105A must be purposefully pushed” by an external element to transition from the UN_OWNED state to the OWNED state. By way of example, consider an IoT device that is loaded with cryptographic keys and credentials at time of manufacture but is otherwise unprepared for any activity e.g., it is in the UN_OWNED state. When given a predetermined “start” signal (not shown),device 105A may use those keys and credentials to set-up a secure channel to the device or component that gave it the “start” signal. Once this is done,device 105A knows its owner but is not otherwise provisioned e.g., it is in the OWNED state. In practice this may be accomplished using an anonymous identification key (AIK) for which some local service vets. There can then be a challenge/response sequence wherein the server (“owner”) authenticates the client (IoT device) using this key only during the “get acquainted” phase, the public key may be used to encrypt a random number or string that can become a shared secret. There are also network protocols, such as the Extensible Authentication Protocol (EAP), that facilitate this exchange in a simple and efficient manner. One advantage of EAP is that the protocol, in tandem with 802.1x switches, allows this exchange to occur prior to authenticated Dynamic Host Configuration Protocol (DHCP) exchanges (i.e., the device may do this prior to ascertaining its IP address). This does not require a full Public Key infrastructure (PKI) implementation; it can be a locally-administered infrastructure. - Referring to
FIG. 4 , shoal-1 110 includesIoT devices 105A-E (seeFIG. 1 ) andshoal context 400 which is shared across all shoal devices. The shoal's shared context, in turn, includes the shoal's current state (current.sstate), its target next state (next.sstate) and identification of a synchronization broker (i.e., a device designated to replicateshoal state 400 to other shoal members). Referring to Table 3, example shoal shared context 400 (and 300) illustrates the types of information that may be used to track a shoal's state. In one embodiment, there isn't necessarily a dominant shoal controller, though one or more devices may be nominated as a synchronization broker for replicating shoal context 400 (at a minimum). Additional devices may also be nominated as shoal service entities supporting security, management and access needs. (The creation of role privileges that all of a shoal's devices recognize and can validate may be part of the credential structure on each device.) Shoal devices may also include cloud and enterprise services, but isolation technologies may need to be used to reasonably ensure the cloud hosted entity is prevented from introducing non-shoal devices/controllers into the shoal. -
TABLE 3 Illustrative Shoal Attributes Attribute Operation Instances Required Description ExternalCred Read Multiple No Credential used to authenticate asymmetric key pair shared among shoal members. InternalCred Read/Write Multiple No Credentials used to authenticate shoal members. McastKey Read/Write Multiple No Data protection key(s) used for shoal disambiguation; intra-shoal communication. [1] Resources Read/Write Multiple No References to resources shared by shoal members. Exclusive Read/Write Multiple No Exclusive tag resources for shoal disambiguation. [1] ACLs Read Multiple No ACL(s) pertaining to shoal resources. Group State Read/Write Single Yes Identifies the operational status of the shoal. Services Read/Write Multiple No Support services that assist with maintenance of shoal operations. Owner(s) Read Multiple Yes Identifies the shoal's authorization resource - [1] If there are multiple shoals in an environment, each must be disambiguated. Note, the shoal name itself may be assigned by a trusted naming authority such as an Internet Domain Naming Service (DNS) also known as DANE DNS (Domain Name System)-Based Authentication of Named Entities. A system in accordance with this disclosure may accept shoal names from a DANE or other naming authority. The Shoal may embed the trust anchor of a DANE authority as part of the shoal resource (e.g. External Cred). The shoal name my be given to a peer shoal or organization network hosting a key distribution service such as Kerberos where the tickets assigned contain the DANE assigned name as the Kerberos ‘realm’ name.
- At the time represented by
FIG. 4 , each device in shoal-1 110 is in a different state. In one embodiment the shoal'scurrent state 405 may be an amalgamation of the respective shoal device states. A reasonable methodology for determining the shoal's current state is to take the most primitive of the shoal's device's state. ComparingFIG. 4 toFIG. 3 or Table 1, the most primitive device state is “OWNED”. The shoal'snext state value 410 is designed to drive all devices to the OPERATIONAL state which, in the example ofFIG. 3 and Table 1, is the state in which the collective function of the shoal may be manifest. Though each device is at a different provisioning state, this does not necessarily mean the devices are not connected and cannot perform operations. They can perform provisioning operations. - Techniques in accordance with this disclosure empower devices, individually and collectively as part of a shoal, to perform self-directed provisioning actions. Shoal state variables may be maintained locally at each device so that each device may independently function to acquire provisioning from accessible/neighboring devices and services. Shoal state variables (e.g., current.sstate and next.sstate) may be synchronized across each shoal member so each knows its own state and the shoal's state. In one embodiment synchronization may be achieved using a group multi-cast or publish-subscribe relays such as the MQTT (formerly Message Queue Telemetry Transport) and Extensible Messaging and Presence Protocol (XMPP) message brokers. Since the group context state variable is the only object that needs to be shared, it is practical to deploy multiple publish-subscribe (Pub-Sub) brokers within the shoal devices themselves. (Publish-subscribe is a messaging pattern where senders of messages (publishers), do not program the messages to be sent directly to specific receivers (subscribers). Instead, published messages are categorized into classes without knowledge of what, if any, subscribers there may be. Similarly, subscribers express interest in one or more classes, and only receive messages that are of interest without knowledge of what, if any, publishers there are.) Unlike a remediation network where the network directs all provisioning objectives, IoT devices as described herein have no need for a centralized manageability server that must be available whenever a device is in remediation.
- Referring to Tables 4 through 6, pseudo-code for a state machine based device provisioning operation in accordance with this disclosure. While not necessarily tied to the illustrative shoal state machine introduced in Tables 1 and 2, this pseudo code does presume that the UNOWNED state resides at one end of the state machine spectrum (e.g., having a value of 0x0000) and OPERATIONAL at the other (e.g., having a value of 0xFFFF). It is believed one of ordinary skill in the art having the benefit of this disclosure will understand that Tables 4-6 capture the operational flow of substantially any state-based device provisioning operation.
-
TABLE 4 Shoal Control Loop DO { CheckPoke( ); /* E.g., set the Shoal's target state to */ /* X, where Shoal.TargetState = X. */ Does <Self> Have SyncBroker Capability? If YES: Nominate <Self> as Sync_Broker Set Timer( ); Else: Return; /* Determine if poke requires group to change status. */ Is Shoal.CurrentState == Shoal.TargetState? If NO: /* Is device's current state aligned with the */ /*shoal's target state? */ { For each device D in Shoal { /* Device needs to either provision or */ /* de-provision something. */ Is D.CurrentState == Shoal.TargetState? If NO: { D.NextState = Shoal.TargetState ChangeMyState(D) } D++; } Shoal.CurrentState = Shoal.TargetState; } } WHILE (ShoalSync( ) == 0) /* I.e., while the shoal's */ /* state is not OPERATIONAL. */ -
TABLE 5 Shoal Synchronization Subroutine ShoalSync( ) Subroutine: { /* Wait for synchronization timer to fire. */ Wait(Timer); If Timer cancelled Then Return ERROR. For each N = FindNextNeighbor(Self) /* Where ‘N’ re- */ IF N == NULL { /* presents a */ Return 0; /* neighbor device. */ } ELSE { /* Synchronize Self's Shoal resource with its */ /* neighbor's Shoal resource */ N.Shoal = Self.Shoal; } } } -
TABLE 6 Device State Change Subroutine ChangeMyState(Self) Subroutine: { Is Self.CurrentState < Self.NextState? If YES: Deprovision MySelf to Self.NextState Else: Provision MySelf to Self.NextState Self.CurrentState = Self.NextState; /* Add Self to device tally in Shoal. */ Shoal[Self].CurrentState = Self.CurrentState; } - One benefit of a state machine based approach to device provisioning is that it can free a system's administrator from micro-managing each device's provisioning operations. In addition, since each device's state machine defines what it may do (but not necessarily how), different devices may perform the same function in different ways—each according to their own operational capabilities. This, in turn, can improve the operational efficiency of a shoal. This same capability permits newer devices to be easily integrated into existing IoT systems (shoals). Other benefits of the disclosed techniques include, but are not limited to use of a group context structure containing goal-oriented provisioning state variables; use of a group context structure that is defined across shoal members; IoT devices with provisioning state variables; use of Trusted Execution Environment (TEE) protocols to permit the protected execution of a shoal entity; use of one (or more) shoal member devices to assist in the provisioning of a neighbor shoal member device; use of a shoal access control structure/policy to enforce access of shoal member resources by other shoal devices and non-shoal devices; use of an attestation method such as, for example, the Enhanced Privacy ID (EPID) and Sigma key exchange protocols to establish a provisioning channel between one IoT device and a sibling IoT device authorized to share provisioning information;
- The following examples pertain to further embodiments.
- Global Claims
- Example 1 is an Internet of Things (IoT) device, comprising: device hardware configured to function in accordance with a type of device; IoT hardware including: a network communication circuit configured to connect to a network communication medium, memory communicatively coupled to the network communication circuit, and a processor operatively coupled to the device hardware, the network communication circuit and the memory, the memory storing instructions that when executed cause the processor to: employ a provisioning state machine corresponding to the type of device and IoT hardware, wherein the provisioning state machine includes a plurality of states, the final state being an operational state, establish a shoal-specific state information in the memory in accordance with the provisioning state machine, establish an IoT device-specific state information in the memory in accordance with the provisioning state machine, establish communication through the network communication circuit with one or more additional IoT devices, wherein the IoT device and each of the one or more additional IoT devices belong to a shoal of IoT devices, determine, based on the established communication, a state of the shoal and record same in the shoal-specific state information, determine a state of the IoT device and record same in the IoT device-specific state information, and sequence through the plurality of states based on a combination of the shoal state and the IoT device state until the IoT device and the one or more additional IoT devices are in the operational state, wherein updated shoal state is received from at least one of the one or more additional IoT devices through the network communication circuit and recorded in the shoal-specific state information.
- In Example 2, the subject matter of Example 1 can optionally include wherein the type of device comprises a pump controller.
- In Example 3, the subject matter of Example 1 can optionally include wherein the network communication medium comprises a wireless network communication medium.
- In Example 4, the subject matter of any one of Examples 1-3 can optionally include wherein the IoT hardware further includes a cryptographic element communicatively coupled to the processor.
- In Example 5, the subject matter of Example 4 can optionally include further comprising instructions stored in the memory that, when executed, cause the processor to use the cryptographic element to establish secure communication with the one or more additional IoT devices.
- In Example 6, the subject matter of any one of Examples 1-3 can optionally include wherein the instructions to cause the processor to sequence through the plurality of states comprise instructions to cause the processor to use a mismatch between the shoal state and the IoT device state to initiate action to move to a new state in accordance with the provisioning state machine.
- In Example 7, the subject matter of any one of Examples 1-3 can optionally include wherein each state in the provisioning state machine has actions associated with provisioning the IoT device.
- Example 8 is an Internet of Things (IoT) operational method, comprising: loading an IoT device with a provisioning state machine control software, wherein the provisioning state machine control software corresponds to the type of IoT device and includes a plurality of states, the final state being an operational state; establishing a shoal-specific state information and a device-specific state information in a memory of the IoT device in accordance with the provisioning state machine; establishing communication through a network communication circuit of the IoT device with one or more additional IoT devices, wherein the IoT device and each of the one or more additional IoT devices belong to a shoal of IoT devices; determining, based on the established communication, a state of the shoal and recording the same in the shoal-specific state information; determining a state of the IoT device and recording the same in the IoT device-specific state information; and sequencing through the plurality of states based on a combination of the shoal state and the IoT device state until the IoT device and the one or more additional IoT devices are in the operational state, wherein updated shoal state is received from at least one of the one or more additional IoT devices through the network communication circuit and recorded in the shoal-specific state information.
- In Example 9, the subject matter of Example 8 can optionally include wherein the type of device comprises a health monitoring system device.
- In Example 10, the subject matter of Example 8 can optionally include wherein the network communication medium comprises a wireless network communication medium.
- In Example 11, the subject matter of any one of Examples 8-10 can optionally include further comprising using a cryptographic element of the IoT device to establish secure communication with at least one of the one or more additional IoT devices.
- In Example 12, the subject matter of any one of Examples 8-10 can optionally include wherein sequencing through the plurality of states comprises using a mismatch between the shoal state and the IoT device state to initiate action to move to a new state in accordance with the provisioning state machine.
- In Example 13, the subject matter of any one of Examples 8-10 can optionally include wherein each state in the provisioning state machine has actions associated with provisioning the IoT device.
- Example 14 is a program storage device comprising instructions stored thereon to cause one or more processors in an Internet of Things (IoT) device to: activate a provisioning state machine corresponding to the IoT device's type, wherein the provisioning state machine includes a plurality of states, the final state being an operational state; establish a shoal-specific state information in a memory of the IoT device in accordance with the provisioning state machine: establish an IoT device-specific state information in the memory in accordance with the provisioning state machine; establish communication through a network communication circuit with one or more additional IoT devices, wherein the IoT device and each of the one or more additional IoT devices belong to a shoal of IoT devices; determine, based on the established communication, a state of the shoal and record the same in the shoal-specific state information; determine a state of the IoT device and record the same in the IoT device-specific state information; and sequence through the plurality of states based on a combination of the shoal state and the IoT device state until the IoT device is in the operational state, wherein updated shoal state is received from at least one of the one or more additional IoT devices through the network communication circuit and recorded in the shoal-specific state information.
- In Example 15, the subject matter of Example 14 can optionally include wherein the instructions to establish communication through a network communication circuit comprise instructions to establish communication through a wireless network communication circuit.
- In Example 16, the subject matter of any one of Examples 14-15 can optionally include wherein the instructions to establish communication through a network communication circuit comprise instructions to establish secure communication through a network communication circuit using a cryptographic element of the IoT device.
- In Example 17, the subject matter of any one of Examples 14-15 can optionally include wherein the instructions to cause the processor to sequence through the plurality of states comprise instructions to cause the processor to use a mismatch between the shoal state and the IoT device state to initiate action to move to a new state in accordance with the provisioning state machine.
- In Example 18, the subject matter of Example 14 can optionally include wherein each state in the provisioning state machine has actions associated with provisioning the IoT device.
- Example 19 is an Internet of Things (IoT) device, comprising: a processor; a memory operatively coupled to the processor, the memory storing instructions that when executed cause the processor to: activate a provisioning state machine corresponding to the IoT device's type, wherein the provisioning state machine includes a plurality of states, the final state being an operational state; establish a shoal-specific state information in a memory of the IoT device in accordance with the provisioning state machine; establish an IoT device-specific state information in the memory in accordance with the provisioning state machine; establish communication through a network communication circuit with one or more additional IoT devices, wherein the IoT device and each of the one or more additional IoT devices belong to a shoal of IoT devices; determine, based on the established communication, a state of the shoal and record the same in the shoal-specific state information; determine a state of the IoT device and record the same in the IoT device-specific state information; and sequence through the plurality of states based on a combination of the shoal state and the IoT device state until the IoT device is in the operational state, wherein updated shoal state is received from at least one of the one or more additional IoT devices through the network communication circuit and recorded in the shoal-specific state information.
- In Example 20, the subject matter of Example 19 can optionally include wherein the instructions to establish communication through a network communication circuit comprise instructions to establish communication through a wireless network communication circuit.
- In Example 21, the subject matter of any one of Examples 19-20 can optionally include wherein the instructions to establish communication through a network communication circuit comprise instructions to establish secure communication through a network communication circuit using a cryptographic element of the IoT device.
- In Example 22, the subject matter of any one of Examples 19-20 can optionally include wherein the instructions to cause the processor to sequence through the plurality of states comprise instructions to cause the processor to use a mismatch between the shoal state and the IoT device state to initiate action to move to a new state in accordance with the provisioning state machine.
- In Example 23, the subject matter of Example 19 can optionally include wherein each state in the provisioning state machine has actions associated with provisioning the IoT device.
- It is to be understood that the above description is intended to be illustrative, and not restrictive. The material has been presented to enable any person skilled in the art to make and use the disclosed subject matter as claimed and is provided in the context of particular embodiments, variations of which will be readily apparent to those skilled in the art (e.g., some of the disclosed embodiments may be used in combination with each other). For example, the above description has assumed the existence of a secure communication environment within which each shoal member operates. This is not strictly required. That is, each shoal member may share credentials with only some (but not all) other shoal members. Further, each shoal may have multiple synchronization members. In one embodiment (such as that described above), a single shoal member may act as the synchronization broker for an entire shoal. In another embodiment, a different synchronization broker may be used for each shoal/group attribute (e.g., calculate shoal state, keep group membership, and credential management). The scope of the invention therefore should be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled. In the appended claims, the terms “including” and “in which” are used as the plain-English equivalents of the respective terms “comprising” and “wherein.”
Claims (18)
Priority Applications (5)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US14/717,754 US9461976B1 (en) | 2015-03-25 | 2015-05-20 | Goal-driven provisioning in IoT systems |
EP16769277.1A EP3275123B1 (en) | 2015-03-25 | 2016-02-25 | Goal-driven provisioning in iot systems |
CN201680030483.7A CN107820699B (en) | 2015-03-25 | 2016-02-25 | Target drives in IoT system are arranged |
PCT/US2016/019648 WO2016153717A1 (en) | 2015-03-25 | 2016-02-25 | Goal-driven provisioning in lot systems |
US15/267,289 US9800468B2 (en) | 2015-03-25 | 2016-09-16 | Goal-driven provisioning in IoT systems |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201562138255P | 2015-03-25 | 2015-03-25 | |
US14/717,754 US9461976B1 (en) | 2015-03-25 | 2015-05-20 | Goal-driven provisioning in IoT systems |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US15/267,289 Continuation US9800468B2 (en) | 2015-03-25 | 2016-09-16 | Goal-driven provisioning in IoT systems |
Publications (2)
Publication Number | Publication Date |
---|---|
US20160285840A1 true US20160285840A1 (en) | 2016-09-29 |
US9461976B1 US9461976B1 (en) | 2016-10-04 |
Family
ID=56975865
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/717,754 Active US9461976B1 (en) | 2015-03-25 | 2015-05-20 | Goal-driven provisioning in IoT systems |
US15/267,289 Active US9800468B2 (en) | 2015-03-25 | 2016-09-16 | Goal-driven provisioning in IoT systems |
Family Applications After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US15/267,289 Active US9800468B2 (en) | 2015-03-25 | 2016-09-16 | Goal-driven provisioning in IoT systems |
Country Status (4)
Country | Link |
---|---|
US (2) | US9461976B1 (en) |
EP (1) | EP3275123B1 (en) |
CN (1) | CN107820699B (en) |
WO (1) | WO2016153717A1 (en) |
Cited By (19)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20160364553A1 (en) * | 2015-06-09 | 2016-12-15 | Intel Corporation | System, Apparatus And Method For Providing Protected Content In An Internet Of Things (IOT) Network |
US20170171196A1 (en) * | 2015-12-14 | 2017-06-15 | Afero, Inc. | System and method for secure internet of things (iot) device provisioning |
US20180063150A1 (en) * | 2016-08-30 | 2018-03-01 | Dwelo Inc. | Connected device rights management administration |
US20180083836A1 (en) * | 2016-09-19 | 2018-03-22 | Amazon Technologies, Inc. | Group Command Management For Device Groups |
WO2018089990A1 (en) * | 2016-11-14 | 2018-05-17 | INTEGRITY Security Services, Inc. | Secure provisioning and management of devices |
WO2018106863A1 (en) * | 2016-12-07 | 2018-06-14 | Northrup Charles | Thing machine systems and methods |
US20180284746A1 (en) * | 2016-05-09 | 2018-10-04 | StrongForce IoT Portfolio 2016, LLC | Methods and systems for data collection optimization in an industrial internet of things environment |
US10116573B2 (en) | 2015-12-14 | 2018-10-30 | Afero, Inc. | System and method for managing internet of things (IoT) devices and traffic using attribute classes |
WO2018236421A1 (en) * | 2017-06-19 | 2018-12-27 | Heldt Sheller Nathan | User-authorized onboarding using a public authorization service |
US10270738B1 (en) * | 2016-09-19 | 2019-04-23 | Amazon Technologies, Inc. | Aggregated group state for a group of device representations |
US10270875B1 (en) * | 2016-09-19 | 2019-04-23 | Amazon Technologies, Inc. | Dynamic grouping of device representations |
US10356088B1 (en) * | 2017-01-25 | 2019-07-16 | Salesforce.Com, Inc. | User authentication based on multiple asymmetric cryptography key pairs |
US10455452B2 (en) | 2015-12-14 | 2019-10-22 | Afero, Inc. | System and method for flow control in an internet of things (IoT) system |
US10581620B2 (en) | 2016-11-14 | 2020-03-03 | Integrity Security Services Llc | Scalable certificate management system architectures |
US11190344B2 (en) | 2017-01-25 | 2021-11-30 | Salesforce.Com, Inc. | Secure user authentication based on multiple asymmetric cryptography key pairs |
US11270223B2 (en) | 2016-09-19 | 2022-03-08 | Charles Northrup | Thing machine |
US11527165B2 (en) * | 2019-08-29 | 2022-12-13 | The Boeing Company | Automated aircraft system with goal driven action planning |
US11663442B2 (en) | 2016-05-09 | 2023-05-30 | Strong Force Iot Portfolio 2016, Llc | Methods and systems for detection in an industrial Internet of Things data collection environment with intelligent data management for industrial processes including sensors |
US11774944B2 (en) | 2016-05-09 | 2023-10-03 | Strong Force Iot Portfolio 2016, Llc | Methods and systems for the industrial internet of things |
Families Citing this family (23)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
KR101634295B1 (en) * | 2014-12-16 | 2016-06-30 | 주식회사 윈스 | System and method for providing authentication service for iot security |
US10175666B2 (en) * | 2015-10-30 | 2019-01-08 | International Business Machines Corporation | Managing internet of things collection having different capabilities |
US9742740B2 (en) * | 2015-11-18 | 2017-08-22 | Adobe Systems Incorporated | Internet of things datapoint engine |
US10938909B2 (en) * | 2015-12-26 | 2021-03-02 | Intel Corporation | Reusable device management in machine-to-machine systems |
US10310832B2 (en) | 2016-02-19 | 2019-06-04 | Intel Corporation | Internet-of-things device blank |
US11146449B2 (en) | 2016-02-19 | 2021-10-12 | Intel Corporation | Network architecture for internet-of-things device |
US10164983B2 (en) * | 2017-01-20 | 2018-12-25 | Verizon Patent And Licensing Inc. | Distributed authentication for internet-of-things resources |
CN108540354A (en) * | 2017-03-02 | 2018-09-14 | 漳州立达信光电子科技有限公司 | Terminal device of network of things and the method for controlling multiple Internet of things device |
CN106941523B (en) * | 2017-03-14 | 2020-10-02 | 深圳蓝奥声科技有限公司 | Health monitoring information acquisition method and system based on Internet of things |
US10298581B2 (en) | 2017-04-28 | 2019-05-21 | Cisco Technology, Inc. | Zero-touch IoT device provisioning |
US10440006B2 (en) | 2017-06-21 | 2019-10-08 | Microsoft Technology Licensing, Llc | Device with embedded certificate authority |
US10938560B2 (en) | 2017-06-21 | 2021-03-02 | Microsoft Technology Licensing, Llc | Authorization key escrow |
US10558812B2 (en) | 2017-06-21 | 2020-02-11 | Microsoft Technology Licensing, Llc | Mutual authentication with integrity attestation |
US10778516B2 (en) | 2017-09-08 | 2020-09-15 | Hewlett Packard Enterprise Development Lp | Determination of a next state of multiple IoT devices within an environment |
US11374760B2 (en) | 2017-09-13 | 2022-06-28 | Microsoft Technology Licensing, Llc | Cyber physical key |
US10693671B2 (en) | 2017-12-18 | 2020-06-23 | Cisco Technology, Inc. | Distributing traffic to multiple destinations via an isolation network |
US11195066B2 (en) | 2018-09-11 | 2021-12-07 | International Business Machines Corporation | Automatic protocol discovery using text analytics |
US11356440B2 (en) | 2018-11-30 | 2022-06-07 | International Business Machines Corporation | Automated IoT device registration |
US11341485B2 (en) | 2019-08-06 | 2022-05-24 | Bank Of America Corporation | Machine learning based system for authorization of autonomous resource transfers between distributed IOT components |
US10921787B1 (en) | 2019-08-06 | 2021-02-16 | Bank Of America Corporation | Centralized resource transfer engine for facilitating resource transfers between distributed internet-of-things (IoT) components |
US11405414B2 (en) | 2019-08-06 | 2022-08-02 | Bank Of America Corporation | Automated threat assessment system for authorizing resource transfers between distributed IoT components |
US11956639B2 (en) | 2020-10-26 | 2024-04-09 | International Business Machines Corporation | Internet of things device provisioning |
US11997759B2 (en) | 2021-09-23 | 2024-05-28 | Skylo Technologies, Inc. | Automated sensor integration and data collection |
Family Cites Families (15)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6975915B2 (en) * | 2002-10-31 | 2005-12-13 | Sap Ag | Cooperative smart items |
US7610584B2 (en) * | 2004-01-02 | 2009-10-27 | International Business Machines Corporation | Method, system, and product for defining and managing provisioning states for resources in provisioning data processing systems |
US8776018B2 (en) * | 2008-01-11 | 2014-07-08 | International Business Machines Corporation | System and method for restartable provisioning of software components |
US20160006815A1 (en) * | 2013-02-19 | 2016-01-07 | Interdigital Patent Holdings, Inc. | Information modeling for the future internet of things |
US9847961B2 (en) * | 2013-02-25 | 2017-12-19 | Qualcomm Incorporated | Automatic IoT device social network expansion |
US9292832B2 (en) * | 2013-02-25 | 2016-03-22 | Qualcomm Incorporated | Collaborative intelligence and decision-making in an IoT device group |
US9853826B2 (en) * | 2013-02-25 | 2017-12-26 | Qualcomm Incorporated | Establishing groups of internet of things (IOT) devices and enabling communication among the groups of IOT devices |
US9413827B2 (en) | 2013-02-25 | 2016-08-09 | Qualcomm Incorporated | Context aware actions among heterogeneous internet of things (IOT) devices |
US9900172B2 (en) * | 2013-04-25 | 2018-02-20 | Qualcomm Incorporated | Coordinated resource sharing in machine-to-machine communication using a network-based group management and floor control mechanism |
MY166564A (en) * | 2013-04-25 | 2018-07-16 | Mimos Berhad | A system and method for privacy management for internet of things services |
WO2014193940A1 (en) * | 2013-05-28 | 2014-12-04 | Convida Wireless, Llc | Load balancing in the internet of things |
US9124563B2 (en) * | 2013-08-19 | 2015-09-01 | Gemalto Sa | Method for asynchronously provisioning keys from one secure device to another |
KR101662396B1 (en) * | 2014-10-13 | 2016-10-05 | 한국과학기술원 | Method and system for controlling device based internet of things |
US9832173B2 (en) * | 2014-12-18 | 2017-11-28 | Afero, Inc. | System and method for securely connecting network devices |
US20160198536A1 (en) * | 2015-01-06 | 2016-07-07 | Kiban Labs, Inc. | Internet-of-things (iot) hub apparatus and method |
-
2015
- 2015-05-20 US US14/717,754 patent/US9461976B1/en active Active
-
2016
- 2016-02-25 WO PCT/US2016/019648 patent/WO2016153717A1/en unknown
- 2016-02-25 CN CN201680030483.7A patent/CN107820699B/en active Active
- 2016-02-25 EP EP16769277.1A patent/EP3275123B1/en active Active
- 2016-09-16 US US15/267,289 patent/US9800468B2/en active Active
Cited By (56)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20160364553A1 (en) * | 2015-06-09 | 2016-12-15 | Intel Corporation | System, Apparatus And Method For Providing Protected Content In An Internet Of Things (IOT) Network |
US10116573B2 (en) | 2015-12-14 | 2018-10-30 | Afero, Inc. | System and method for managing internet of things (IoT) devices and traffic using attribute classes |
US20170171196A1 (en) * | 2015-12-14 | 2017-06-15 | Afero, Inc. | System and method for secure internet of things (iot) device provisioning |
US11330473B2 (en) | 2015-12-14 | 2022-05-10 | Afero, Inc. | System and method for flow control in an internet of things (IoT) system |
US10455452B2 (en) | 2015-12-14 | 2019-10-22 | Afero, Inc. | System and method for flow control in an internet of things (IoT) system |
US10171462B2 (en) * | 2015-12-14 | 2019-01-01 | Afero, Inc. | System and method for secure internet of things (IOT) device provisioning |
US11774944B2 (en) | 2016-05-09 | 2023-10-03 | Strong Force Iot Portfolio 2016, Llc | Methods and systems for the industrial internet of things |
US20180284746A1 (en) * | 2016-05-09 | 2018-10-04 | StrongForce IoT Portfolio 2016, LLC | Methods and systems for data collection optimization in an industrial internet of things environment |
US20200096990A1 (en) * | 2016-05-09 | 2020-03-26 | Strong Force Iot Portfolio 2016, Llc | Systems and methods for removing background noise in an industrial pump environment |
US11797821B2 (en) | 2016-05-09 | 2023-10-24 | Strong Force Iot Portfolio 2016, Llc | System, methods and apparatus for modifying a data collection trajectory for centrifuges |
US11770196B2 (en) * | 2016-05-09 | 2023-09-26 | Strong Force TX Portfolio 2018, LLC | Systems and methods for removing background noise in an industrial pump environment |
US11755878B2 (en) | 2016-05-09 | 2023-09-12 | Strong Force Iot Portfolio 2016, Llc | Methods and systems of diagnosing machine components using analog sensor data and neural network |
US11728910B2 (en) | 2016-05-09 | 2023-08-15 | Strong Force Iot Portfolio 2016, Llc | Methods and systems for detection in an industrial internet of things data collection environment with expert systems to predict failures and system state for slow rotating components |
US11663442B2 (en) | 2016-05-09 | 2023-05-30 | Strong Force Iot Portfolio 2016, Llc | Methods and systems for detection in an industrial Internet of Things data collection environment with intelligent data management for industrial processes including sensors |
US11838036B2 (en) | 2016-05-09 | 2023-12-05 | Strong Force Iot Portfolio 2016, Llc | Methods and systems for detection in an industrial internet of things data collection environment |
US11836571B2 (en) | 2016-05-09 | 2023-12-05 | Strong Force Iot Portfolio 2016, Llc | Systems and methods for enabling user selection of components for data collection in an industrial environment |
US11646808B2 (en) | 2016-05-09 | 2023-05-09 | Strong Force Iot Portfolio 2016, Llc | Methods and systems for adaption of data storage and communication in an internet of things downstream oil and gas environment |
US11996900B2 (en) | 2016-05-09 | 2024-05-28 | Strong Force Iot Portfolio 2016, Llc | Systems and methods for processing data collected in an industrial environment using neural networks |
US10484389B2 (en) * | 2016-08-30 | 2019-11-19 | Dwelo, Inc. | Connected device rights management administration |
US20180063150A1 (en) * | 2016-08-30 | 2018-03-01 | Dwelo Inc. | Connected device rights management administration |
US11743266B2 (en) | 2016-08-30 | 2023-08-29 | Level Home, Inc. | Connected device rights management administration |
US11057391B2 (en) * | 2016-08-30 | 2021-07-06 | Dwelo Inc. | Connected device rights management administration |
US11270223B2 (en) | 2016-09-19 | 2022-03-08 | Charles Northrup | Thing machine |
US20180083836A1 (en) * | 2016-09-19 | 2018-03-22 | Amazon Technologies, Inc. | Group Command Management For Device Groups |
US10270738B1 (en) * | 2016-09-19 | 2019-04-23 | Amazon Technologies, Inc. | Aggregated group state for a group of device representations |
US10887174B2 (en) * | 2016-09-19 | 2021-01-05 | Amazon Technologies, Inc. | Group command management for device groups |
US10270875B1 (en) * | 2016-09-19 | 2019-04-23 | Amazon Technologies, Inc. | Dynamic grouping of device representations |
US11704596B2 (en) | 2016-09-19 | 2023-07-18 | Charles Northrup | Thing machine |
US11283892B1 (en) * | 2016-09-19 | 2022-03-22 | Amazon Technologies, Inc. | Dynamic grouping of device representations |
US11271896B1 (en) * | 2016-09-19 | 2022-03-08 | Amazon Technologies, Inc. | Aggregated group state for a group of device representations |
KR20210059003A (en) * | 2016-11-14 | 2021-05-24 | 인테그리티 시큐리티 서비시즈 엘엘씨 | Secure provisioning and management of devices |
US10956542B2 (en) | 2016-11-14 | 2021-03-23 | Integrity Security Services Llc | Secure provisioning and management of devices |
US10762178B2 (en) | 2016-11-14 | 2020-09-01 | Integrity Security Services Llc | Secure provisioning and management of devices |
KR102347659B1 (en) | 2016-11-14 | 2022-01-05 | 인테그리티 시큐리티 서비시즈 엘엘씨 | Secure provisioning and management of devices |
US11138294B2 (en) | 2016-11-14 | 2021-10-05 | Integrity Security Services Llc | Secure provisioning and management of devices |
US10599819B2 (en) | 2016-11-14 | 2020-03-24 | Integrity Security Services Llc | Secure provisioning and management of devices |
KR102253814B1 (en) | 2016-11-14 | 2021-05-18 | 인테그리티 시큐리티 서비시즈 엘엘씨 | Secure provisioning and management of devices |
US10581620B2 (en) | 2016-11-14 | 2020-03-03 | Integrity Security Services Llc | Scalable certificate management system architectures |
US11997220B2 (en) | 2016-11-14 | 2024-05-28 | Integrity Security Services Llc | Scalable certificate management system architectures |
KR20200125778A (en) * | 2016-11-14 | 2020-11-04 | 인테그리티 시큐리티 서비시즈 엘엘씨 | Secure provisioning and management of devices |
US11586709B2 (en) | 2016-11-14 | 2023-02-21 | Integrity Security Services Llc | Secure provisioning and management of devices |
US10503881B2 (en) | 2016-11-14 | 2019-12-10 | Integrity Security Services Llc | Secure provisioning and management of devices |
WO2018089990A1 (en) * | 2016-11-14 | 2018-05-17 | INTEGRITY Security Services, Inc. | Secure provisioning and management of devices |
US11153101B2 (en) | 2016-11-14 | 2021-10-19 | Integrity Security Services Llc | Scalable certificate management system architectures |
KR20190083336A (en) * | 2016-11-14 | 2019-07-11 | 인테그리티 시큐리티 서비시즈 엘엘씨 | Security provisioning and management of devices |
KR102216322B1 (en) | 2016-11-14 | 2021-02-17 | 인테그리티 시큐리티 서비시즈 엘엘씨 | Secure provisioning and management of devices |
KR20210018546A (en) * | 2016-11-14 | 2021-02-17 | 인테그리티 시큐리티 서비시즈 엘엘씨 | Secure provisioning and management of devices |
KR102174665B1 (en) | 2016-11-14 | 2020-11-05 | 인테그리티 시큐리티 서비시즈 엘엘씨 | Secure provisioning and management of devices |
US11769062B2 (en) | 2016-12-07 | 2023-09-26 | Charles Northrup | Thing machine systems and methods |
WO2018106863A1 (en) * | 2016-12-07 | 2018-06-14 | Northrup Charles | Thing machine systems and methods |
US10356088B1 (en) * | 2017-01-25 | 2019-07-16 | Salesforce.Com, Inc. | User authentication based on multiple asymmetric cryptography key pairs |
US11190344B2 (en) | 2017-01-25 | 2021-11-30 | Salesforce.Com, Inc. | Secure user authentication based on multiple asymmetric cryptography key pairs |
WO2018236421A1 (en) * | 2017-06-19 | 2018-12-27 | Heldt Sheller Nathan | User-authorized onboarding using a public authorization service |
US11832102B2 (en) | 2017-06-19 | 2023-11-28 | Intel Corporation | User-authorized onboarding using a public authorization service |
US11337070B2 (en) | 2017-06-19 | 2022-05-17 | Intel Corporation | User-authorized onboarding using a public authorization service |
US11527165B2 (en) * | 2019-08-29 | 2022-12-13 | The Boeing Company | Automated aircraft system with goal driven action planning |
Also Published As
Publication number | Publication date |
---|---|
US20170005871A1 (en) | 2017-01-05 |
EP3275123B1 (en) | 2021-06-09 |
EP3275123A1 (en) | 2018-01-31 |
US9461976B1 (en) | 2016-10-04 |
CN107820699A (en) | 2018-03-20 |
WO2016153717A1 (en) | 2016-09-29 |
US9800468B2 (en) | 2017-10-24 |
CN107820699B (en) | 2019-02-26 |
EP3275123A4 (en) | 2018-10-10 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9800468B2 (en) | Goal-driven provisioning in IoT systems | |
US11750609B2 (en) | Dynamic computing resource access authorization | |
US10382203B1 (en) | Associating applications with Internet-of-things (IoT) devices using three-way handshake | |
KR102113910B1 (en) | Automatic identification of invalid participants in a secure synchronization system | |
EP3512155A1 (en) | Method and system for providing secure access to artifacts in a cloud computing environment | |
JP6255091B2 (en) | Secure proxy to protect private data | |
EP3656107B1 (en) | Secure real-time clock update in an access control system | |
JP2021505098A (en) | Systems and methods for recording device lifecycle transactions as a versioned block of a blockchain network using transaction connectors and broker services | |
JP2021505097A (en) | Device identification systems and methods for enrollment and registration of connected endpoint devices, as well as blockchain services | |
US20180288617A1 (en) | Transferable ownership tokens for discrete, identifiable devices | |
KR20110122731A (en) | Introducing encryption, authentication, and authorization into a publication and subscription engine | |
US11843601B2 (en) | Methods, systems, and computer readable mediums for securely establishing credential data for a computing device | |
Yung et al. | Security issues and mitigation in ethernet powerlink | |
Walz et al. | PROFINET security: A look on selected concepts for secure communication in the automation domain | |
US11930115B2 (en) | Management of devices joining a network | |
US11722569B1 (en) | System and method for providing a virtual media gateway using a systems management console | |
JP2018067327A (en) | Secure proxy for protecting private data | |
CN111698299B (en) | Session object replication method, device, distributed micro-service architecture and medium | |
Pi | Secure bootstrapping and access control in NDN-based smart home systems | |
Zhang | Secure and Practical Splitting of IoT Device Functionalities | |
Kim | Secure Programming Platform for Edge-Based IoT: Wild-and-Crazy-Idea Paper | |
NZ761969B2 (en) | Secure real-time clock update in an access control system | |
Neumann | Anonymous Electronic Identity in Cross-Border and Cross-Sector Environments |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: MCAFEE, INC., CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:SMITH, NED M.;SCHRECKER, SVEN;SIGNING DATES FROM 20150422 TO 20150514;REEL/FRAME:035683/0387 |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |
|
AS | Assignment |
Owner name: MCAFEE, LLC, CALIFORNIA Free format text: CHANGE OF NAME AND ENTITY CONVERSION;ASSIGNOR:MCAFEE, INC.;REEL/FRAME:043665/0918 Effective date: 20161220 |
|
AS | Assignment |
Owner name: JPMORGAN CHASE BANK, N.A., NEW YORK Free format text: SECURITY INTEREST;ASSIGNOR:MCAFEE, LLC;REEL/FRAME:045055/0786 Effective date: 20170929 Owner name: MORGAN STANLEY SENIOR FUNDING, INC., MARYLAND Free format text: SECURITY INTEREST;ASSIGNOR:MCAFEE, LLC;REEL/FRAME:045056/0676 Effective date: 20170929 |
|
MAFP | Maintenance fee payment |
Free format text: PAYMENT OF MAINTENANCE FEE, 4TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1551); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY Year of fee payment: 4 |
|
AS | Assignment |
Owner name: MORGAN STANLEY SENIOR FUNDING, INC., MARYLAND Free format text: CORRECTIVE ASSIGNMENT TO CORRECT THE REMOVE PATENT 6336186 PREVIOUSLY RECORDED ON REEL 045056 FRAME 0676. ASSIGNOR(S) HEREBY CONFIRMS THE SECURITY INTEREST;ASSIGNOR:MCAFEE, LLC;REEL/FRAME:054206/0593 Effective date: 20170929 Owner name: JPMORGAN CHASE BANK, N.A., NEW YORK Free format text: CORRECTIVE ASSIGNMENT TO CORRECT THE REMOVE PATENT 6336186 PREVIOUSLY RECORDED ON REEL 045055 FRAME 786. ASSIGNOR(S) HEREBY CONFIRMS THE SECURITY INTEREST;ASSIGNOR:MCAFEE, LLC;REEL/FRAME:055854/0047 Effective date: 20170929 |
|
AS | Assignment |
Owner name: MCAFEE, LLC, CALIFORNIA Free format text: RELEASE OF INTELLECTUAL PROPERTY COLLATERAL - REEL/FRAME 045055/0786;ASSIGNOR:JPMORGAN CHASE BANK, N.A., AS COLLATERAL AGENT;REEL/FRAME:054238/0001 Effective date: 20201026 |
|
AS | Assignment |
Owner name: MCAFEE, LLC, CALIFORNIA Free format text: RELEASE OF INTELLECTUAL PROPERTY COLLATERAL - REEL/FRAME 045056/0676;ASSIGNOR:MORGAN STANLEY SENIOR FUNDING, INC., AS COLLATERAL AGENT;REEL/FRAME:059354/0213 Effective date: 20220301 |
|
AS | Assignment |
Owner name: JPMORGAN CHASE BANK, N.A., AS ADMINISTRATIVE AGENT AND COLLATERAL AGENT, NEW YORK Free format text: SECURITY INTEREST;ASSIGNOR:MCAFEE, LLC;REEL/FRAME:059354/0335 Effective date: 20220301 |
|
AS | Assignment |
Owner name: JPMORGAN CHASE BANK, N.A., AS ADMINISTRATIVE AGENT, NEW YORK Free format text: CORRECTIVE ASSIGNMENT TO CORRECT THE THE PATENT TITLES AND REMOVE DUPLICATES IN THE SCHEDULE PREVIOUSLY RECORDED AT REEL: 059354 FRAME: 0335. ASSIGNOR(S) HEREBY CONFIRMS THE ASSIGNMENT;ASSIGNOR:MCAFEE, LLC;REEL/FRAME:060792/0307 Effective date: 20220301 |
|
MAFP | Maintenance fee payment |
Free format text: PAYMENT OF MAINTENANCE FEE, 8TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1552); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY Year of fee payment: 8 |