Data management system and method using explicit private networking techniques - Patents.com

Abstract

The present disclosure relates, among other things, to managing data communicated between systems, services, and / or devices using explicit private networking techniques that provide relatively robust end-to-end security. In some embodiments, explicit private networking techniques may protect data in transit and / or at rest and / or in use in potentially hostile environments. In various embodiments, an explicit private networking technique architecture may protect connected device data by encrypting it where and when the data is generated, and maintain that protection until the data is consumed in a trusted information platform and / or service that uses identity and access management services to identify, authenticate, and / or grant permissions to read, modify, and / or work with the data, and / or control the device, and / or issue associated device commands.

Description

[Technical field]

[0001] (Related Applications) This application claims the benefit of priority under 35 U.S.C. §119(e) to U.S. Provisional Patent Application No. 63 / 283,099, filed November 24, 2021, and entitled “DATA MANAGEMENT SYSTEMS AND METHODS USING EXPLICIT PRIVATE NETWORKING TECHNIQUES,” the contents of which are incorporated herein by reference in their entirety.

[0002] (Copyright Granted) Portions of the disclosure of this patent document may contain material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction of either the patent document or the patent disclosure, as appearing in the U.S. Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever. Summary of the Invention

[0003] The present disclosure relates generally to systems and methods for managing data communicated between systems, services, and / or devices, and more particularly, but not exclusively, the present disclosure relates to managing data communicated between systems, services, and / or devices using explicitly private networking techniques that provide relatively robust end-to-end security.

[0004] As the number of sensor- and actuator-based systems and / or devices connected to the Internet increases, so do the security challenges associated therewith. Such systems and / or devices may be generally referred to in certain instances as connected devices and / or "things" and, when communicatively connected to other systems, devices, and / or services, become part of the Internet-of-things ("IoT"). The proliferation of connected devices has led to the development of protocols for wide-area networks, neighborhood-area networks, local-area networks, and / or personal-area networks, which are primarily designed and implemented to address challenges associated with the security of connected devices.

[0005] Many connected devices are designed to be relatively small, low power, and utilize relatively inexpensive hardware. These considerations also influence the network parameters associated with such devices. As such, many connected devices have relatively low computational and / or data throughput requirements (e.g., allowing some devices to be deployed with only intermittent network connectivity).

[0006] Connected devices may be intended to be "secure," but the concept of security often takes a back seat to minimizing cost and / or power consumption and battery life. The security challenge is further exacerbated because connected things tend to be highly distributed, decentralized, and / or physically available to attackers, creating a large attack surface even for simple non-mission-critical applications. For consumer IoT devices, another issue is that many manufacturers may not be willing or able to build effective security into their devices. This low barrier to entry leads to increased opportunities for attackers, and the lower the cost of an attack, the more likely it may be.

[0007] Many IoT devices and systems manage mission-critical real-time systems such as oil and gas pipelines, power grids, semi-autonomous vehicles, and building systems. Due to the efficiencies they introduce, these "commercial" IoT systems are proliferating, making them targets for an ever-increasing number of cyberattacks. However, many of the protocols used in today's IoT were never designed with today's threat model in mind, which currently includes nation-state actors waging cyberwarfare, and well-funded and technologically skilled criminal gangs operating under the aegis of aggressive nation states.

[0008] In some instances in the IoT space, network protocols may be used that do not have robust inherent security. Furthermore, hardware implementing such protocols may have limited or no hardware protection capabilities. For example, controller area network (CAN) buses within vehicles may not implement a concept of identity for component communication and / or authentication, allowing a compromised vehicle infotainment system under attack to issue commands to more critical connected systems (e.g., braking systems). Many Supervisory Control and Data Acquisition (SCADA) systems that form the mission-critical backbone of utilities may use the Modbus communication protocol. However, Modbus has not traditionally implemented robust authentication capabilities.

[0009] The power grid is perhaps one of the world's largest machines, however, it can also be one of its most vulnerable. The transition from a hierarchically controlled system to a hyperconnected, cyber-physical, market-driven system capable of precise, near-instantaneous synchronization of supply and demand requires rigorous attention to secure system design. The benefits of large-scale smart grids risk not being fully realized until we have a truly secure, reliable, and decentralized infrastructure for IoT devices that can ensure that many resources can be safely, optimally, and quickly utilized when they come online, and are protected from the risks associated with malicious actors.

[0010] Securing connected devices in the IoT presents a myriad of challenges and / or security constraints including, for example, but not limited to, relatively inexpensive hardware that may have limited secure hardware and / or software resources (e.g., secure enclaves); connected devices that have less persistence and only intermittent connectivity; devices that may be widely distributed and / or more physically accessible, thereby creating a large attack surface; utilization of multiple network topologies and / or networks; mesh-based edge networks where device data is collected at a head end and then communicated through a provider's network before being received by cloud-based IoT management systems and / or services; and / or fragmented networks that bridge relatively complex technical and / or administrative operational and / or information technology differences.

[0011]

[0013] Embodiments of the disclosed systems and methods enable secure management and / or communication of data between connected devices, systems, and / or associated services. In some implementations, embodiments of the disclosed systems and methods can ameliorate various security concerns and / or challenges associated with IoT networks and connected devices, as described herein.

[0012] Consistent with various disclosed embodiments, data communicated between systems, services, and / or devices may be managed using explicit private networking techniques (EPN), which provide relatively robust end-to-end security. EPN techniques consistent with embodiments disclosed herein may use secure cryptographic key establishment protocols in architectures that may include many-to-many relationships. In some embodiments, EPN techniques may protect data in transit and / or at rest and / or in use in potentially hostile environments. In further embodiments, data protected using EPN techniques may be encrypted and / or decrypted in trusted and / or otherwise protected processing environments. Various embodiments of the security infrastructure described herein may enable reliable, fluid, low latency, and / or automated market mechanisms using, for example, but not limited to, network-independent EPN, advanced attribute-based identity management, and / or data and control authentication and authorization mechanisms.

[0013] In certain embodiments, IoT devices can pair with digital twins to keep the devices simple, focused, and / or responsive during operation. In some embodiments, those digital twins may employ artificial intelligence mechanisms to detect and share anomalies and threats, continuously upgrade device security, and / or employ self-healing strategies. In further embodiments, digital twins can be used to allow authorized users to access and / or manipulate data from associated IoT devices while keeping the associated devices behind a firewall and thereby unable to be directly accessed. This can allow less secure devices to communicate with EPN services and associated digital twins through the EPN without being directly accessed by users and / or potentially malicious actors.

[0014] Various embodiments of the disclosed systems and methods may also comprise a responsive, distributed, and trusted management infrastructure that authenticates and / or otherwise interacts with attributes of devices, services, data feeds, and / or software components. Users may access and / or manipulate data from IoT devices, and certain embodiments disclosed herein may enable authenticating such users and implementing robust access control of interactions between actors (e.g., users and / or programs) in the EPN ecosystem. Embodiments of the present disclosure further describe an interoperable infrastructure that may enable participation from providers of devices and / or services. The working operation of the present invention will be readily understood by reference to the following detailed description taken in conjunction with the accompanying drawings. [Brief description of the drawings]

[0015] [Figure 1]1 illustrates a conceptual diagram showing non-limiting examples of various sources and destinations of data within a data management ecosystem consistent with certain embodiments disclosed herein. [Diagram 2] 1 illustrates a non-limiting example of an explicit private network system architecture consistent with certain embodiments disclosed herein. [Diagram 3] 1 illustrates a diagram of a non-limiting example of an explicit private network ecosystem consistent with certain embodiments disclosed herein. [Figure 4] 1 illustrates a flow diagram of a non-limiting example of a method for managing connected devices in an explicit private network ecosystem consistent with certain embodiments disclosed herein. [Diagram 5] Illustrates an example of a system that can be used to implement certain embodiments of the systems and methods of the present disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0016] In this specification, a description of a system and method consistent with the embodiments of the present disclosure is provided. Although several embodiments are described, it should be understood that the present disclosure is not limited to any one embodiment, but instead encompasses numerous alternatives, modifications, and equivalents. In addition, numerous specific details are set forth in the following description to provide a thorough understanding of the embodiments disclosed herein, but some embodiments can be practiced without some or all of these details. Moreover, for the sake of clarity, certain technical material that is known in the relevant art has not been described in detail to avoid unnecessarily obscuring the disclosure.

[0017] Embodiments of the present disclosure can be understood by reference to certain drawings. The components of the disclosed embodiments can be arranged and designed in a wide variety of configurations, as generally described and / or illustrated in the figures herein. Thus, the following description of embodiments of the systems and methods of the present disclosure is not intended to limit the scope of the disclosure, but is merely representative of possible embodiments of the present disclosure. In addition, the steps of any method disclosed herein do not necessarily have to be performed in any particular order, nor sequentially, nor do steps have to be performed only once, unless otherwise specified.

[0018] The reliability and / or usefulness of modern IoT systems may depend, at least in part, on a high degree of trust in the data that is generated and consumed. Unlike certain conventional methods of protecting IoT data, EPN techniques consistent with certain embodiments of the disclosed systems and methods may provide data integrity, authentication, and / or confidentiality from data generation to consumption and back again. Some conventional IoT system protection mechanisms may include the use of network-based link protection, from Zigbee mesh field area networks to WIFI to Bluetooth, but network-based link protection is typically deployed insecurely and may only provide protection of the link but not necessarily the data throughout its lifecycle. Transport Layer Security (TLS) and Virtual Private Networks (VPNs) may be somewhat better, but can only protect data in transit, not data at rest. In certain implementations, EPN techniques consistent with various disclosed embodiments can provide true end-to-end protection, potentially without the performance penalty of asymmetric cryptosystems used in traditional digital signatures, authentication (e.g., X.509 certificate validation), and / or public key cryptography techniques used in providing confidentiality. In some implementations, techniques using short-lived symmetric keys can be used.

[0019] Embodiments of the disclosed systems and methods implementing EPN techniques may help address various data management issues and / or concerns associated with conventional solutions. EPN techniques may include, for example, but are not limited to: ■ Reduce malicious and / or accidental modification and / or spoofing of data. ■Improves data security compared to traditional IoT networking protocols (e.g., ModBus and / or CAN bus, which have no ability to authenticate and / or identify devices, and / or ZWAVE and / or Zigbee, which have limited security features). ■ It provides better end-to-end protection compared to protocols that only consider certain parts of the "pipe." ■ Addressing the challenges of information technology / operations technology convergence. Data traversing widespread field area networks with many devices from different vendors poses very complex data management problems, and trusting the authenticity and / or integrity of data is difficult in a heterogeneous environment. The embodiments disclosed herein can provide a common root of trust across this complexity, enabling management of fragmented trust systems under a conceptual "single pane of glass."

[0020] Embodiments of the disclosed systems and methods can use EPN techniques to provide mechanisms to ensure that data is protected when communicated to, from, and / or between connected devices, clouds, and / or other devices, systems, and / or services. EPN techniques consistent with embodiments disclosed herein can protect IoT data by encrypting it when it is generated where it is generated, and maintain that protection until it is consumed in a trusted information platform and / or service that uses identity and access management ("identity and access management (IAM") services to identify, authenticate, and / or grant permissions to read, modify, and / or interact with that data. In some embodiments, authorization can also be employed, among other things, to perform possible filtering of that data based on applicable rules and / or policies to determine what data and / or commands may be sent to the device, to determine what data may be read from the device, and / or to limit access to private information used to communicate such data and / or commands in a trusted manner, etc.

[0021] Explicit Private Networks Overview A connected device may generate data (e.g., via one or more associated sensors) and / or act as a data source in various contexts, applications, and / or use cases. A connected device may further act as an actuator that controls and / or otherwise commands other devices, systems, and / or services to take certain actions. For example, without limitation, a connected device may respond to peak demand information associated with an electrical grid by turning off a large electrical load (e.g., an air conditioning unit) in certain cases.

[0022] To maintain trust, privacy, safety, and / or security ("TPSS") in connection with connected device networks, various embodiments disclosed herein may leverage trusted endpoints that may be located on the network edge and / or in the cloud. Consistent with embodiments disclosed herein, EPN techniques may be used to protect data as it passes through one or more untrusted gateways and / or networks between trusted endpoints. This trust may be leveraged to protect data as it travels across a data network to reach the cloud.

[0023] In various examples and / or embodiments described herein, certain network connections and / or intermediate gateways, systems, devices, and / or services and / or endpoints may be described as "trusted" and / or "untrusted". However, it will be understood that such trust is relative and trust may be considered from the perspective of a particular endpoint. For example, a network connection and / or gateway may have certain network and / or security protections, but from the perspective of an endpoint originating and / or receiving data through the network connection and / or gateway, the network connection and / or gateway may not necessarily be trustworthy. Similarly, an endpoint originating data may trust the network connection and / or associated intermediate services, but the receiving endpoint may not share this trust. Thus, a network connection may be considered "untrusted" even though one endpoint considers the network connection to be "trusted" because trust is not shared by both endpoints.

[0024] It will further be appreciated that trust in a network connection and / or associated intermediate gateways, systems, devices, and / or services may depend, at least in part, on the type of data and / or operations communicated over the network connection and / or through the intermediate gateways, systems, devices, and / or services, and / or other contextual information. For example, an endpoint may trust a network connection for data with relatively low security implications, but such trust may not extend to certain other data (e.g., device actuation commands) that have higher security requirements. Thus, trust in a network connection and / or gateways may depend, at least in part, on the type of data being communicated over the connection and / or other contextual considerations. In light of the above, it will be appreciated that the terms "trusted" and / or "untrusted" may be used to describe whether an endpoint trusts a network connection and / or associated intermediate gateways, systems, devices, and / or services, possibly in light of the particular type of data being communicated and / or various other contextual information.

[0025] Consistent with embodiments of the disclosed systems and methods, the EPN technique can address a number of design considerations, including, for example, but not limited to, one or more of the following: ■ User-Centric System Properties. As EPN ecosystems proliferate and grow, their complexity may increase. TPSS properties associated with various connected devices and / or related systems and / or services can act as system-level attributes that enable user review, interaction, and / or verification. In certain embodiments, augmented intelligence can be used to manage the EPN ecosystem at scale. ■ Systematic growth. In certain embodiments, the EPN ecosystem can accommodate relatively rapid evolution and growth. New entities can be added to the network while ensuring that existing entities that depend on the new entities (e.g., connected devices) understand the TPSS implications of adding the new entity. ■ Maintenance. In various embodiments, changes to the EPN ecosystem and / or aspects and / or faults thereof can be identified relatively quickly, allowing for rapid and reliable maintenance, updates, and / or adaptation. ■ Simplicity and relatively low overhead. As mentioned above, certain connected devices participating in the EPN ecosystem may be relatively low-capability devices. To improve the effectiveness of trust management, trust can be delegated and / or otherwise distributed to devices and / or entities with improved capabilities to enforce TPSS-like considerations. ■ Support for Legacy Entities. In some circumstances, certain connected devices may have legacy properties that can be adapted to participate in the EPN ecosystem and implement TPSS considerations. Various embodiments of an EPN ecosystem consistent with embodiments disclosed herein can be adapted to support legacy entities. Performance, flexibility, and / or scale. The embodiments disclosed herein can implement an EPN and support a TPSS without significantly impacting the performance of associated devices, systems, and / or services and / or the ability to grow the EPN ecosystem. ■ Interoperability. Various embodiments may enable different entities to contribute to and / or be part of the EPN ecosystem and to interact constructively with relatively minimal and / or otherwise easy adaptation to participate.

[0026] Explicit Private Network Implementation Concepts and Entities Various embodiments of the disclosed systems and methods can include and / or otherwise involve various policies, data, models, actions, and / or entities. For example, without limitation, an EPN ecosystem can include and / or otherwise involve one or more of the following implementation concepts, policies, data types, models, actions, and / or entities: ■ Policy A policy may represent a set of rules that may drive decisions regarding the behavior, permissions, and / or operational privileges of an entity associated with a TPSS-like decision. ■ Control Actions: A control action may represent an action that can cause a connected device to take an action and / or otherwise "do something." This may include, for example, but is not limited to, granting access to data and / or resources. ■ Internal Data. Internal data may include, for example, device state information including, but not limited to, current state, past state, future state, and / or other factual information about connected devices and / or things. External Data. External data may include data acquired and / or otherwise generated by the connected device using one or more associated sensor systems. In some embodiments, external data may include data regarding the environment proximate to the connected device. ■ Trust Model. Consistent with embodiments disclosed herein, a trust model can provide a formal description of how different entities and / or components within an ecosystem depend on each other to operate and / or authorize actions and / or possess certain attributes and / or capabilities in a particular context. In some embodiments, the trust model can include delegation, whereby an entity can grant and / or transfer authority to another. ■ Device Manufacturer. A device manufacturer may manufacture a connected device. In some embodiments, the connected device may be shipped with a "factory configuration," which may include default and / or initial policies, configuration values, and / or other settings. ■ Device Owner. A device owner can establish root policies to control the device and / or manage access to the device's resources. In some embodiments, the root policies may be used in conjunction with a reference monitor for the device. ■ Delegation: Delegation can involve an entity being delegated the authority to make decisions regarding access to resources by another entity. A controller may include a connected device that is capable of controlling the actions of another connected device. A user and / or a program and / or an associated system may also act as a controller. ■ Security Associations. Security associations can define access permissions between connecting devices, users, and / or programs. For example, but not by way of limitation, for a given connecting device, a security association can include entries in a table that list other entities that may be conditionally authorized to have access to resources provided by the given connecting device. In some embodiments, an entry can list an entity ID, associated cryptographic parameters, one or more explicit permissions, and / or other attributes that a policy evaluator can use to determine authorization with reference to device state and / or device attributes. ■ Reference Monitor. A reference monitor may be part of a system that filters action requests and / or determines how to respond to those requests by applying policies that may reference the resources specified in the request, the system state, the identity of the requester, and / or the security association between the system and the requester. In some embodiments, requests may be subject to authentication using cryptographic parameters listed in the associated security association. If permitted, responses to the request may be protected using cryptographic parameters listed in the security association. ■ Digital Twin. A digital twin can include a virtual digital copy and / or representation of a physically connected device and / or system. In some embodiments, a virtual twin may have additional available resources compared to the corresponding physical device and / or system. The digital twin may be stored and / or otherwise managed by a cloud service and / or another service point (e.g., a gateway). In at least one non-limiting example, this may allow the digital twin to act as a proxy for the associated device and / or system, but with additional security resources to insulate the device and / or system from harm and / or better protect the device and / or system from malicious actors. In some embodiments, this may enable connected devices to have a highly secure association with their corresponding digital twin, particularly in relation to applications, contexts, and / or use cases that do not require low latency, allowing much of the burden of the reference monitor to be offloaded to the digital twin.

[0027] Various entities relevant to the disclosed systems and methods (e.g., connected devices, users, programs, and / or associated systems and / or services) can be conceptually considered as sources and / or destinations in certain contexts. For example, without limitation, a connected device may be a source of data (e.g., data generated by one or more sensor systems of the connected device) and a cloud service associated with the connected device may be a destination of the data. It will be appreciated that, depending on the context, a device, system, and / or service may act as both a source of data and a destination of data published by one or more other devices, systems, and / or services.

[0028] Additionally, while generally described in certain examples herein as "sources" and / or "destinations" of data, it will be understood that such data may include commands and / or actions. Thus, source devices, systems, and / or services may act as actuators and / or otherwise act to issue commands to one or more destination devices, systems, and / or services, which may take certain actions depending on the context as dictated by the received command. Depending on the context, devices, systems, and / or services may act as actuators for other devices, systems, and / or services or as destinations for such commands.

[0029] 1 illustrates a conceptual diagram showing non-limiting examples of various sources 100-106 and destinations 110-116 of data in a data management ecosystem consistent with certain embodiments disclosed herein. As shown, sources of data may include, for example, but not limited to, one or more connected devices 100, one or more cloud services 102 and / or associated systems, one or more data centers 104 and / or other data stores, one or more databases 106, and / or any other device, system, and / or service that may generate, store, and / or otherwise provide data for access by one or more data destinations. Similarly, destinations of data may include, for example, but not limited to, one or more connected devices 110, one or more cloud services 112 and / or associated systems, one or more data centers 114 and / or other data stores, one or more databases 116, and / or any other device, system, and / or service that may receive, use, access, and / or otherwise be destined for data generated and / or provided by one or more data sources.

[0030] It will be understood that various other types of sources and / or destinations may be included in a data management ecosystem consistent with certain embodiments disclosed herein. For example, but not by way of limitation, although not specifically illustrated in connection with FIG. 1, users and / or applications may operate as actors in the EPN ecosystem, as sources and / or destinations. As discussed in more detail below, users and / or applications may, for example, but not by way of limitation, access and / or manipulate data generated by connected devices, generate derived data from raw data generated by connected devices, issue commands to control connected devices, etc.

[0031] As noted above, depending on the context, a device, system, and / or service can act as both a source of data and a destination of data issued by one or more other devices, systems, and / or services. For example, and without limitation, connected device 100 may be a source of data provided to one or more other connected devices, systems, stores, and / or services, but may also be a destination of data generated by another connected device 110. Thus, although the sources and destinations in FIG. 1 are illustrated separately for purposes of explanation and illustration, it will be understood that a connected device and / or associated systems, stores, services, etc. may act as both a data source and a destination.

[0032] A wide variety of connected devices 100, 110 may be used in connection with various disclosed embodiments. For example, but not limited to, the connected devices may include one or more of a computer system, a smartphone, a tablet computing system, a security system, a vehicle infotainment system, a streaming media device, a gaming device, an entertainment system, a network lock, a thermostat, a furnace, an air conditioning system, an irrigation system, a water control system, a pump system, a utility meter, a network gateway, an activity sensor, a home alarm, an appliance, a vehicle and / or a vehicle component and / or subsystem, a mobile communication device, a wind turbine system, a solar panel system, an industrial manufacturing control system, and / or any other type of connected device and / or system. Thus, it will be understood that the particular examples of connected devices 100, 110 and / or associated systems and / or sources 102-106 and destinations 112-116 described herein should be considered as illustrative to facilitate an understanding of the disclosed embodiments, and not as limiting.

[0033] The data source and destination may be communicatively coupled via one or more network connections that may include one or more intermediate devices, systems, and / or services 108. The intermediate devices, systems, and / or services 108 may include various devices, systems, and / or services, which may include various computing systems, network infrastructure devices, gateways, and / or systems, and / or other connected devices. For example, without limitation, the connected device 100 may communicate sensor data to the destination cloud service 112 via a network that includes several intermediate network connections and / or nodes and / or supporting gateway systems. In another non-limiting example, the connected device 100 may communicate the sensor data to another intermediate connected device (e.g., a hub, etc.), which may communicate the sensor data to the destination cloud service 112. Although the various embodiments illustrated in connection with FIG. 1 show sources and destinations being communicatively coupled via one or more intermediary devices, systems, and / or services 108, it will be further understood that the sources and destinations of data may be communicatively coupled via one or more direct network connections that do not necessarily involve intermediate devices, systems, and / or services 108.

[0034] In certain circumstances, intermediate devices, systems, and / or services 108 and / or associated network connections may not necessarily be trusted and / or secure from the perspective of the endpoints, and / or the trust and / or security of such devices, systems, and / or services 108 and / or associated network connections may not necessarily be known to the endpoints. Furthermore, as discussed above, in certain embodiments, intermediate network devices, systems, and / or services 108 and / or associated network connections may only be partially trusted (and thus not fully trusted) and / or may only be trusted in certain contexts (e.g., trusted when communicating certain low-security data, etc.). Consistent with embodiments disclosed herein, EPN techniques may be used to protect data between trusted endpoints (e.g., trusted sources and destinations) as the data passes through one or more untrusted intermediate devices, systems, and / or services 108. In this manner, EPN techniques may enable endpoints to communicate in a trusted manner without necessarily relying on the trust of the network connections and / or the intermediate devices, systems, and / or services 108.

[0035] Explicitly Private Network Architecture and Ecosystem Consistent with embodiments of the disclosed systems and methods, the EPN ecosystem may include one or more of connected devices, an EPN session manager service, an IoT service, an EPN secret manager service and / or associated stores, an EPN administrator service, a certificate authority, an IAM service, one or more web clients, and / or one or more applications, systems, services, and / or devices that implement aspects of the EPN using set up EPN device and / or server software development kits ("SDKs").

[0036] In certain embodiments, a connecting device may contact a certificate authority as part of a device personalization process. For example, but not by way of limitation, a device certificate including a public device key may be generated by the certificate authority and issued to the connecting device. As discussed below, this certificate may be used in a connection to establish an EPN session.

[0037] Establishing trusted communications between the connecting device and the EPN ecosystem may involve a session establishment process. Consistent with embodiments disclosed herein, as part of the session establishment process with the EPN session manager service, the connecting device may be authenticated using a suitable authentication protocol. In some embodiments, a Station-to-Station ("STS") protocol may be used. Upon successful authentication, a shared session key may be established for communications between the connecting device and the EPN session manager service. In certain embodiments, the certificate generated during the personalization process may be stored in the EPN session data during session establishment.

[0038] Secure data communication between various connected devices and / or one or more applications and / or services may be achieved following a session establishment process. For example, but not by way of limitation, a connected device may interact with an IoT service that manages a database to enable the device to store, access, and / or otherwise use data stored in the database. In connection with such secure data communication, one end of the communication (e.g., the connected device and / or service) may create a secure envelope for the data by encrypting the data using a shared secret and / or signing the data using a private or secret key. The other endpoint of the communication may decrypt the data using the shared secret and / or verify the signature using a stored public or private key.

[0039] In certain embodiments, a secret store associated with an EPN secret manager service may be used as secure, durable, and / or tamper-resistant storage for established EPN session data. An EPN server SDK in the EPN ecosystem may interact with the EPN secret manager service to retrieve EPN session data from the secret store for processing packet data. For example, but not by way of limitation, the retrieved EPN session data may be used in connection with encryption / decryption and / or signing / verification of packet data. In some embodiments, communication with the EPN secret manager may occur over a secure and / or otherwise trusted network connection (e.g., a TLS connection, etc.).

[0040] The EPN session manager service may include a web service for establishing EPN sessions with EPN-enabled connected devices. In some embodiments, the EPN administrator service contacts the EPN session manager service and / or leverages other methods to provide a list of configured security domains, which may be used to validate connected device group configurations.

[0041] The EPN session manager service can store the successfully negotiated session data in a secret store managed by the EPN secret manager service. The EPN session data stored for an authenticated device may include a variety of information, including, for example, one or more of the following, but is not limited to: ■A unique session ID. ■ A wrapped key may include a shared session secret wrapped by a security domain key corresponding to the security domain of the device. ■Client certificate. ■ View security domains. ■ Session expiration information. ■ Protection mode information, indicating whether session secret information can be used in conjunction with encryption / decryption and / or signature operations. ■Digest of session data.

[0042] In various embodiments, the EPN session data may be protected against tampering. When new EPN session data is saved to a secret store, a digest of that data may be calculated and stored in a database. When a session record is read, the digest may be recalculated and verified against the stored digest value. In certain embodiments, a blockchain and / or other trusted immutable ledger may store and / or otherwise use various digest values ​​for verification purposes.

[0043] Various aspects of the disclosed embodiments may be implemented using one or more SDKs for building EPN-enabled client, device, and / or server applications. For example, without limitation, the EPN client SDK may provide a binary library for integrating EPN functionality into connected device applications. The EPN client SDK may support EPN session establishment through interacting with an EPN session manager service and / or generating EPN secure messages (which may be referred to as EPN envelopes in certain embodiments). In some embodiments, the EPN client SDK may be used to interact with a trusted certificate authority service in connection with personalizing connected devices.

[0044] The EPN server SDK may integrate EPN functionality into server and / or service applications. The EPN server SDK may support recovery of messages from EPN secure envelopes, which may include, for example, but are not limited to, encrypted data, signed data, and / or a combination of signed and / or encrypted data. The EPN server SDK may also support creating an EPN envelope from a plaintext message.

[0045] Consistent with embodiments disclosed herein, EPN techniques may be integrated into an IoT service. In at least one non-limiting example, an IoT service may include a trusted data management service that manages access to data generated by one or more connected devices and contained in a time series database ("TSDB"). In some embodiments, the IoT service may act as a web proxy to redirect EPN communications from connected devices to the TSDB, managing access to the TSDB so that only authorized connected devices can store and query data within the TSDB, and ensuring that any communications with devices are secure and / or trusted end-to-end.

[0046] The EPN ecosystem may further comprise an EPN administrator service. The EPN administrator service may also include web services that may be used to manage the configuration of devices and / or device groups. In some embodiments, configuration information for such devices and / or groups may be stored and / or otherwise managed in a configuration store managed by the EPN administrator service. In some embodiments, the EPN administrator service may leverage IAM services in connection with controlling access to the configuration of devices and / or groups. Through this interaction, only authenticated users (and / or associated devices) with the relevant permissions may create, view, modify, and / or delete EPN administrator device group objects.

[0047] In certain embodiments, a connecting device may be authenticated during the EPN session establishment process. The connecting device may present a certificate as part of the authentication process from a trusted certificate authority service (e.g., trusted directly and / or indirectly via a trust anchor in a trust store).

[0048] In some embodiments, a security partitioning technique may be employed whereby connecting devices may be configured as part of a security domain, allowing devices from multiple organizations to interoperate. Each security domain may utilize different keys to protect session data for devices within the security domain. Devices may be configured into one or more device groups, which may be identified by associated identities contained in certificates. The identities contained in certificates may be verified during EPN session establishment to determine which device group a device belongs to.

[0049] 2 illustrates a flow chart of a non-limiting example of an EPN system architecture consistent with certain embodiments disclosed herein. Among other things, the depicted architecture shows interactions that may occur as part of a personalization process for a connected device 200, a session establishment process between the connected device 200 and an EPN session manager service 204, secure communications with an IoT service 202, a process for accessing a secret in a secret store 232 using an EPN secret manager service 206, and / or interactions between an IoT service 202 and an IAM service 212.

[0050] In certain embodiments, connected device 200 may comprise a protected, secure, and / or otherwise trusted execution environment ("TEE") 224. In certain embodiments, TEE 224 may be implemented with secure hardware and / or software components and may be configured to perform sensitive operations such as, for example, but not limited to, cryptographic operations, secure policy and / or data management, and / or other aspects of the disclosed embodiments. Among other things, TEE 224 may provide secure boot and / or secure storage capabilities to connected device 200.

[0051] In some embodiments, TEE 224 may be established and / or otherwise configured on connected device 200 using an EPN client SDK. Among other things, the EPN client SDK may facilitate personalization and / or authentication, session establishment, and / or secure message processing functionality of connected device 200. As illustrated in connection with FIG. 2 and described in detail herein, implementing EPN functionality within connected device 200 may enable the device to communicate with other systems and / or services in a relatively secure manner over an untrusted network connection.

[0052] Connected device 200 may be configured at the factory or through a personalization, setup, and / or initialization process that may use a shared secret that may be used to identify device 200. In certain embodiments, the shared secret may be unique to connected device 200. In further embodiments, the shared secret may be shared among a group of devices.

[0053] For example, but not by way of limitation, as part of the personalization process, connected device 200 may generate an asymmetric key pair. Connected device 200 may send the shared secret and public key to certificate authority 216, which may operate as a cloud-based service. Certificate authority 216 may generate and return a public key certificate and / or token to connected device 200. In certain embodiments, the returned certificate and / or token may serve as an identity of connected device 200 within the EPN ecosystem in connection with various interactions disclosed herein. In further embodiments, other device personalization processes and / or techniques may be used, including, but not limited to, a FIDO Device Onboarding ("FDO") process.

[0054] In some embodiments, the TEE 224 may be involved in a personalization process with the certificate authority 216 of the connected device 200. For example, the TEE 224 may provide a secure and / or otherwise protected environment for generating and / or storing private information, such as private keys.

[0055] Prior to interacting with various other components of the EPN ecosystem, connecting device 200 may contact EPN session manager service 204 to establish an EPN session. In some embodiments, connecting device 200 may interact with EPN session manager service 204 over an untrusted connection. For example, but not by way of limitation, connecting device 200 may communicate identifying information, which may include a public key certificate, to EPN session manager service 204 along with a session initiation request. As a result of this interaction, a symmetric session key may be generated by EPN session manager service 204 and issued to connecting device 200, which may be used by connecting device 200 in connection with securing communications within the EPN ecosystem.

[0056] Once the connected device 200 establishes an EPN session, the EPN client SDK of the connected device 200 may store the session key in the secure storage of the TEE 224. The connected device 200 may then use the EPN session key to facilitate secure communications with other endpoints in the EPN ecosystem. For example, but not by way of limitation, the connected device may communicate with the IoT service 202 to access data stored in the TSDB store 226 managed by the IoT service 202. Communications issued from the connected device 200 may be encrypted and / or signed using the EPN session key to provide security and / or integrity even though the associated communication channel may be insecure and / or untrusted. While various embodiments and examples described herein may use the EPN session key in connection with effectuating secure communications over an insecure and / or untrusted channel, it will be understood that in further embodiments, keys generated and / or otherwise derived from the EPN session key may be used.

[0057] As discussed in more detail below, in certain embodiments, connected device 200 may communicate with digital twin 220 using an EPN session key (and / or keys derived therefrom). Digital twin 220 may comprise a virtual digital copy and / or representation of connected device 200 (possibly along with additional resources available to the connected device). In certain embodiments, digital twin 220 may be accessible to authorized applications (e.g., web client 210) and / or users 236, with access managed using governance functionality of IoT services 202 and IAM services 212.

[0058] In one particular embodiment, the digital twin 220 may be provided as part of the IoT service 202, and interactions with the digital twin are managed by queries and responses issued to the IoT service 202. In further embodiments, the digital twin 220 may be provided via one or more separate systems and / or services.

[0059] The EPN session manager service 204 may communicate with the EPN secret manager service 206 over a secure channel. For example, without limitation, in some embodiments, the EPN session manager service 204 may communicate with the EPN secret manager service 206 over a channel secured using mutual TLS. The EPN secret manager service 206 may manage an associated secret store 232, in which EPN session keys established between the connected device 200 and the EPN session manager service 204 may be securely stored, associated, and / or managed.

[0060] A user 236 of an application, such as web client 210 (and / or any associated devices and / or systems with which the user 236 is associated) can authenticate with an IAM service 212, which can manage an access control directory 228. Once authenticated, the user 236 can receive an access token from the IAM service 212. The received access token may be used by the user 236 for authentication and to aid in communication with the EPN administrator user interface ("UI") 210 and / or applications built using the EPN server SDK.

[0061] The EPN administrator UI 210 can enable authorized users and / or applications to manage the connected device 200 and / or other connected devices and / or things in the IoT ecosystem. The EPN administrator UI 210 can interact with an EPN administrator service 208, which can, among other things, manage a store 230 that stores connected device configuration information (e.g., configuration information related to the connected device 200). The EPN administrator service 208 can invoke an IAM service 212 and / or an EPN secret manager service 206.

[0062] In certain embodiments, groups of connected devices may be defined, so that a symmetric key for the group may be created and stored by EPN secret manager service 206 (e.g., secret store 232). Certain functions of EPN secret manager service 206 may, in some embodiments, be accessible to EPN administrator service 208. In some embodiments, EPN administrator service 208 may perform an access check with IAM service 212 to determine whether a given user is permitted to manage devices and / or device groups.

[0063] Users and / or associated systems 236 may engage with various services through applications, which in some embodiments may include the web client 214. For example, users and / or associated systems 236 may use the web client 214 to interact with one or more applications 218, the IoT service 202, the IAM service 212, and / or the EPN administrator UI 210. In further embodiments, users and / or associated systems 236 may engage with services directly. In certain embodiments, users and / or associated systems 236 may interact with the IoT service 202 (e.g., directly and / or via the web client 214) to query data collected by the connected devices 202, which may be managed within the TSDB 226. The IoT service 202 may apply data governance (e.g., via rules and / or permissions provided by the IAM service 212) to manage access to such data.

[0064] In various embodiments, a service (e.g., IoT service 202) may expose an API that may be invoked via the web client 214 and / or by other clients, applications, services, systems, and / or devices. For example, in certain embodiments, APIs exposed by IoT service 202 may be invoked using scripts, applications, and / or command line interactions other than a web client.

[0065] To send commands to the connected device 200 on behalf of a user and / or associated system 236, the IoT service 202 may engage the EPN Secret Manager service 206 to retrieve the appropriate session and / or group keys for the connected device 200. In certain embodiments, this operation may also be governed, leveraging rules and / or policies maintained in the directory 228 of the IAM service 212 to determine whether the requesting user and / or system 236 is authorized to perform a particular operation on the connected device 200. If authorized, the IoT service 202 may leverage an embedded EPN Server SDK to encrypt, sign, decrypt, and / or verify messages between the IoT service, the connected device 200, and / or the digital twin 220.

[0066] 2 are illustrated as separate services and / or components of an IoT ecosystem, it will be appreciated that a particular service and / or component may be implemented by a single system and / or service and / or any suitable combination of systems and / or services. For example, without limitation, in some embodiments, EPN session manager service 204, EPN secret manager service 206, EPN administrator service 208, and / or EPN administrator UI 210 may be implemented by a single service that provides a particular EPN functionality.

[0067] 3 illustrates a diagram of a non-limiting example of an explicit private network ecosystem consistent with certain embodiments disclosed herein. Consistent with embodiments disclosed herein, one or more connected devices 300, which may include, for example, but are not limited to, any of the types of connected devices detailed herein, may be personalized and registered with the EPN network via a personalization and EPN session establishment process. The EPN network may include a data management service 306 and / or one or more data stores 302. In some embodiments, the EPN network may further include one or more external identity providers (e.g., Active Directory Federation Services ("ADFS"), Open ID / Connect, OAuth2, Security Assertion Markup Language ("SAML"), Lightweight Directory Access Protocol ("LDAP"), etc.).

[0068] For example, applications 318 and / or data consumers 316, which may include, but are not limited to, users, services, models, IoT analytics channels, etc., may interact with the EPN network to view, modify, analyze, and / or otherwise view data collected from and / or generated by connected devices 300. In further embodiments, applications 318 may also process the data to generate models and / or derived data. The generated models and / or derived data may be stored and / or otherwise managed by the data virtualization service 310.

[0069] In some embodiments, data consumers 316 and / or applications 318 may have access to data that is governed via rules and / or policies managed by the IAM service 308 and / or data virtualization service 310, which in some embodiments may be a service provided by the data management service 306 (although it could also be implemented by a separate service that communicates with the data management service 306).

[0070] The data store 302 may be managed by a data management service 306. For example, without limitation, in some embodiments, the data management service 306 may manage access to the data store 302 by various parties (e.g., connected devices 300, data consumers 316, applications 318, and / or data controllers and / or manipulators 320) via API calls issued to the data management service 306.

[0071] The data controller and / or manipulator 320 may communicate with the data management service 306 to send commands and / or other messages to one or more connected devices 300, which may be processed by the connected devices 300 depending on the nature of the command and / or message. Consistent with embodiments disclosed herein, the sending of commands to the connected devices 300 may be governed by the data management service 306. For example, in some embodiments, the data management service may leverage the IAM service 308 to ensure that rules and / or policies established by the EPN administrator 322 are enforced. In some embodiments, the IAM service 308 may leverage one or more external identity providers 304 to leverage single sign on ("single sign on, SSO") and / or external authentication, if the EPN ecosystem is configured to allow such external authentication.

[0072] Data consumers 316, applications 318, and / or data controllers and / or manipulators 320 may deploy programs within the TEE 312 of the data management service 306 according to rules and / or policies established by the EPN administrator 322. The TEE 312 may, among other things, prevent export outside of the TEE 312. Programs executing in the TEE 312 may, for example, but not by way of limitation, analyze, enhance, and / or augment data associated with the connected device 300, and in some cases generate derived data based on the ingested data. In some embodiments, the programs may enable authorized data consumers 316 to access the origin data, derived data, and / or enhanced data via one or more APIs exposed by the data management service 306 and / or the programs themselves.

[0073] The data virtualization service 310 of the data management service 306 may manage data sets and / or data sources (e.g., managed internally and / or located in external data stores 302). Consistent with embodiments disclosed herein, access to those data sets and / or data stores 302 may be governed using rules enforced by the data virtualization service 310 and / or the data management service 306 with the assistance of the IAM service 308.

[0074] The data management services may further include an audit service 314. In some embodiments, the audit service 314 may maintain an authoritative log of all accesses to data and / or commands associated with the connected device 300. The authoritative log may further include an indication of received queries and / or commands specified by the data consumers 316, applications 318, and / or data controllers and / or manipulators 320.

[0075] Connected Device Control Using Explicit Private Network Techniques - Patent application 4 illustrates a flow diagram of a non-limiting example of a method 400 for managing connected devices in connection with an EPN ecosystem consistent with certain embodiments disclosed herein. The illustrated method 400 may be implemented in a variety of manners, including using software, firmware, hardware, and / or any combination thereof. In a particular embodiment, various aspects of the illustrated method 300 and / or constituent steps thereof may be performed by a cloud services system configured to enable users and / or associated applications and / or systems to interact with one or more connected devices and / or any other suitable devices, systems, and / or services and / or combinations of devices, systems, and / or services.

[0076] At 402, a device command request may be received from a cloud services system. In some embodiments, the device command request may be received from an application associated with a user over a trusted and / or otherwise secure network connection. For example, but not by way of limitation, the device command request may be received over a network communication channel secured by TLS.

[0077] The device command request may include a variety of information. For example, in certain embodiments, the device command request may include a requestor identity that may identify the requesting user, application, and / or system, and may be used in authenticating such identity with an IAM service that manages access control and / or associated privileges, permissions, and / or restrictions. In some embodiments, the requestor identity may include an access token (e.g., an access token issued by an associated IAM service). In further embodiments, the device command request may further include a connected device identity and an indication of the requested action to be performed by the connected device.

[0078] At 404, an access authorization query may be issued to the IAM service. In a particular embodiment, the access authorization query may include a requestor identity. The access authorization query may further include a connected device identity and / or an identification of the requested action in some implementations.

[0079] At 406, a response may be received from the IAM service based on the access authorization query. In some embodiments, the response may validate the requestor identity. For example, without limitation, the response may validate token information provided from the cloud services system to the IAM service as part of the access authorization query. In further embodiments, the response may include information providing at least one permission, rule, and / or restriction associated with controlling at least one operation of the connected device associated with the connected device identity.

[0080] At 408, it may be determined whether an account associated with the requester identity (e.g., an account associated with the requesting application, system, and / or associated user) is authorized to perform the requested device action on the connected device. In some embodiments, this determination may be based on at least one permission, rule, and / or restriction returned from the IAM service and an indication of the requested device action included in the device command request. If the action is not authorized, method 400 may proceed to termination and / or an indication of failure may be returned to the requesting system. If the requested action is authorized, the method may proceed to 410.

[0081] At 410, a first EPN key query may be issued to an EPN service (e.g., an EPN secret manager service). In some embodiments, the EPN key query may include connected device identification information (e.g., an identification token, etc.). The EPN service may manage, among other things, a key association table that associates one or more connected devices registered with the EPN service with one or more EPN session keys. The session keys may include, for example, but are not limited to, a device session key and / or a group session key. The EPN service may respond to the query with a session key associated with the connected device identification information (assuming an active session key is included in the key association table associated with the EPN service).

[0082] The cloud service system may generate a connected device command at 412 configured to instruct the connected device to perform the requested action indicated in the device command request. In some embodiments, the connected device command may be signed and / or encrypted using a session key provided by the EPN service. The cloud service system may send the generated connected device command to the connected device over a connection that is not necessarily trusted.

[0083] In some embodiments, method 400 may further include a command acknowledgment process. For example, the connecting device may communicate an acknowledgment to the cloud service system that the command was received and / or otherwise successfully executed by the connecting device. In some embodiments, the cloud service system may verify that a session key used to sign and / or otherwise encrypt the acknowledgment from the connecting device is active and / or otherwise not expired (e.g., by querying an EPN service to verify the revocation status of the session key).

[0084] It will be appreciated that embodiments of the disclosed systems and methods may be employed in connection with a variety of connected devices and / or associated networks and / or ecosystems. For example, but not by way of limitation, embodiments may be utilized in the deployment of IoT devices and / or sensors that collect data and transmit that data to one or more cloud data repositories, proprietary databases, data analytics providers, etc. for storage and / or processing. Similar non-limiting examples arise within specialized industrial applications, such as distributed manufacturing management and control systems and / or smart grid management and control systems, where IoT sensors and / or actuators are widely deployed to collect operational and / or environmental data that may be transmitted to a variety of disparate and / or competing systems for storage and / or analysis.

[0085] It will be further understood that embodiments of the disclosed systems and methods may be employed in a variety of applications, contexts, and / or use cases, and may, in some implementations, include various aspects and / or constituent steps of the method 400 illustrated in connection with Figure 4. For example, but not by way of limitation, as detailed herein, embodiments of the disclosed systems and methods may enable a user to query data generated by a connected device that is populated within a TSDB, a user to manage and / or configure connected devices and / or device groups, a program to query data stored within a TSDB managed by a service and generate derived data and / or models from the queried data (which may be executed within a secure environment), a connected device to populate a TSDB managed by a service, etc.

[0086] Managing connected devices with digital twins As detailed above, in some embodiments, the digital twin may be used to configure and / or otherwise manage security associations and / or state information for IoT connected devices. For example, but not limited to, the digital twin may be used to initialize and / or configure security associations and / or key exchange protocols, including, but not limited to, symmetric keys and / or other key exchange protocols. Authenticated key exchange may be performed using a variety of methods and / or suitable techniques, some of which may include group keys (e.g., as may be the case in a local network).

[0087] Consistent with embodiments disclosed herein, as a trusted entity within an application cloud, the digital twin can enable trusted services to update and / or provide the following: ■Keys used for authentication, data integrity, and / or confidentiality. ■ A trusted environment for updating device settings. ■ A reference monitor for repairing devices to a known good state.

[0088] Various embodiments disclosed herein can facilitate proof for anti-cloning. For example, a secret can be embedded in the device and persisted in the digital twin for the life of the device. This secret can be used to prove the uniqueness of the device, for example, using an HMAC of the immutable device identity with a session key.

[0089] Data protection from the sensor edge to cloud services Unlike certain conventional techniques for protecting data (e.g., using TLS or VPNs), the EPN techniques disclosed herein, in some implementations, can provide end-to-end data integrity, authentication, and / or data confidentiality for all data from when it is generated at the edge to when it is consumed in an application (e.g., cloud and / or mobile application). Various embodiments implementing the EPN architectures disclosed herein can provide persistent data protection ("PDP") to ensure data integrity, authenticity, and / or optionally confidentiality both at rest and in transit, even as it travels across potentially untrusted gateways and networks.

[0090] In various embodiments, EPN techniques may be used to sign and optionally encrypt data as it is generated on the device. Similar protection may be provided for data sent to the device (e.g., when commands are sent to the device). In certain embodiments, the PDP protection layer implemented by EPN techniques can coexist with network security measures such as VPNs, but continue to provide protection after the VPN pipe has delivered its contents to a VPN gateway and when the data is stored.

[0091] Consistent with embodiments disclosed herein, an EPN client (e.g., an EPN SDK implementation) may be installed on each endpoint. In some embodiments, the EPN client may be configured to ensure that sensitive processes and / or operations are executed in the TEE and / or another secure processing environment, and sensitive cryptographic key data is stored in secure storage.

[0092] In certain embodiments, device software may be expected to be digitally signed to ensure that only known and trusted software runs on the endpoint. This can be verified at startup by a trusted boot process. EPN clients may rely on secure foundations such as a TEE and / or trusted storage and / or trusted boot to ensure resilient protection of data. In some embodiments, these foundations may be enabled through a combination of key infrastructure toolsets and integration with hardware security of associated hardware and / or device components.

[0093] In at least one non-limiting example, the connected device may include an analog sensor. When an analog input is sensed by the sensor, the input may be processed by an analog-to-digital converter ("analog-to-digital, A / D"). Once the digital data is generated, the EPN client may have access to a buffer with the data and may sign the data using an EPN session key associated with a particular trusted key space. The signature may ensure the authenticity of the data originating from a particular endpoint (e.g., using keyed hash and / or HMAC authenticity verification techniques). In some embodiments, the integrity of the data throughout its journey may also be verifiable through the use of a hash operation. Optionally, the EPN client may also encrypt the data to maintain confidentiality of the data. Because many connected devices may be performance and / or resource constrained, EPN techniques consistent with embodiments disclosed herein may leverage AES symmetric key ciphers. These ciphers may be agreed upon between the client and server using, for example, but not by way of limitation, the Diffie-Hellman STS protocol, and thus may or may not require the distribution of secrets.

[0094] In some embodiments, the EPN package may include routing data for a consuming server that may act as an EPN endpoint. When the server receives the EPN package, it may perform an HMAC verification to verify the authenticity and / or integrity of the data packets in the package. If encryption has been applied, the server may decrypt the data. Further distribution, collaboration, and sharing of the data is managed using other data access control features of the services provided by the server.

[0095] As noted above, the EPN's focus on data authenticity and data integrity consistent with the embodiments disclosed herein can provide persistent protection of data throughout untrusted networks and / or across untrusted gateways and / or routers. EPN techniques can ensure that data from IoT devices is trustworthy, and this trust can be maintained throughout its journey, including when commands and other data are transmitted to actuators.

[0096] Personalization for connected devices As discussed above, a certificate authority may provide a personalization service that issues trusted authentication information (e.g., certificates, certificates and keys, and / or other trusted assertions). The certificate authority service may also issue symmetric keys that are bound to device identities. In some embodiments, the derivation functions used to generate and / or otherwise issue keys may be kept secure.

[0097] A client SDK that is aware of the personalization service may be implemented, such as, but not limited to, ■ Engage in personalization protocols with certificate authorities and / or provide secure storage of secrets and credentials. ■Provide an API for the device owner to invoke the above and establish a secure connection to some endpoint using credentials and keys, and obtain secure data from it that is potentially more application specific (e.g. a trust anchor for a backend service), and / or encrypt the data sent over some communication channel and wrap this data so that the receiver can trust its integrity / confidentiality.

[0098] The personalization service may accept requests from authenticated and / or authorized callers to reveal some of the data issued to a particular device, such as a symmetric key that encrypts the data.

[0099] Various embodiments may provide device and / or personality management capabilities, which may include, for example, but not limited to, updating device settings (e.g., sensor polling frequency, connections to other devices at the edge (P2P), etc.), pushing firmware updates (e.g., signed firmware updates), updating and / or replacing keys, revoking a device and / or otherwise removing it from the network, setting up secrets used for device attestation (anti-cloning) (e.g., HMAC using a session key and device identity), etc.

[0100] In certain embodiments, lightweight high performance data protection may be implemented using DUPKT keys and / or HMAC on the data (e.g., data integrity, authentication, and optionally confidentiality). Various embodiments may allow for updating settings and / or sending commands to devices (e.g., setting update - change sensor reading interval) and / or sending instructions for actuators (e.g., change rotation speed of a wind turbine).

[0101] From Named Data Networking to Data-Centric Security Certain embodiments may implement a named data network ("NDN") and / or aspects thereof. In certain NDN implementations consistent with aspects of the disclosed embodiments, data may be signed with its name to generate a secure binding. The signature and / or associated data issuer information may be used in connection with determining the provenance of the data. For example, but not by way of limitation, in some embodiments implementing NDN techniques, a data consumer may make a context-specific determination regarding a particular public key to determine whether it is associated with an entity that can be trusted to issue particular data. In some implementations, the key may be packaged as NDN data. Applications may manage access to data by encrypting the data and distributing the associated key as NDN data.

[0102] In certain embodiments, the certificate authority functionality and / or the personalization and / or key management services may be provided standalone (e.g., without needing to be integrated with a trusted data management service). In some embodiments, some of the rules and / or policies may be reflected on the client and cryptographically verified by the client through a certificate available on the client. In a non-limiting example, if an authorized user obtains a ticket from a trusted service indicating that the user is authorized to adjust the pitch of a windmill directly from his / her phone, the windmill can verify the ticket presented by the user even without an internet connection.

[0103] Server applications can be authenticated using the IAM protocol. In certain implementations, once in the TSDB, the data may not need to be protected via a session key derivation key, and thus server applications can process the data without necessarily having access to the session key.

[0104] In at least one non-limiting example, the data management process can include one or more of the following: (1) A user may log in to a client application (browser, smartphone application). (2) Authenticating a server application using the user identity. ■Authentication information for this may be provided by a certification authority. ■Server applications can use the IAM service to authenticate to the data management platform and thereby provide the data management platform with the appropriate role to determine how to expose data in the secure execution environment. (3) The authenticated identity may be used to determine permissions to the tagged data. The tagged data may include client-generated metadata within the message package to specify a digital rights management style context, which may include, for example, but not limited to, the following: ■ Who has access, the location where the data was generated (e.g., latitude and / or longitude), can include more course data for the user (e.g., cell sector ID), more granular data (e.g., GPS data), etc. ■ Enabling data access scenarios such as when data may be accessed (eg, time windows), data expiration dates, and / or "try before you buy" data. (4) Encrypted data from the edge may be decrypted within the TSDB and then controlled by a trusted service, and access may then be regulated by a secure execution environment. (5) Trust associations may be managed by real-time services, which may include, for example, but not limited to, per-device key management, key updates, updated metadata generation, etc. In some embodiments, a trusted ledger may be used to maintain efficient and relatively lightweight distributed permissioning.

[0105] Image Verification and Signing Various embodiments of the disclosed systems and methods can support image verification and / or signing. In some embodiments, this can be performed at firmware update time and / or at boot time. The boot loader can be verified by the platform. The boot loader can use the client SDK to verify the kernel image and transfer control to the kernel image. In some embodiments, the kernel can use the client SDK to verify the application image and / or transfer control to the application. The application can use the client SDK APIs, secure messages, and / or keys from a non-volatile key store on the system for other communications over a secure channel.

[0106] System and / or Service Architecture 5 illustrates an example system 500 that may be used to implement certain embodiments of the systems and methods of the present disclosure. Various systems, services and / or devices used in connection with aspects of the disclosed embodiments may be communicatively coupled using a variety of networks and / or network connections (e.g., network 508). In certain embodiments, network 508 may include a variety of network communication devices and / or channels and may utilize any suitable communication protocols and / or standards that facilitate communication between the systems and / or devices.

[0107] Network 508 may include the Internet, a local area network, a virtual private network, and / or any other communications network utilizing one or more electronic communications technologies and / or standards (e.g., Ethernet, etc.). In some embodiments, network 508 may include a wireless carrier system, such as a personal communications system ("PCS"), and / or any other suitable communications system incorporating any suitable communications standards and / or protocols. In further embodiments, network 508 may include analog mobile communications networks and / or digital mobile communications networks utilizing, for example, code division multiple access (CDMA), Global System for Mobile Communications or Groupe Special Mobile (GSM), frequency division multiple access (FDMA), and / or time division multiple access (TDMA), long-term evolution (LTE), orthogonal frequency-division multiplexing (OFDM), and the like. In certain embodiments, network 508 may incorporate one or more satellite communications links. In still further embodiments, network 508 may utilize the IEEE 802.11 standard, Bluetooth, ultra-wide band (UWB), Zigbee, and / or any other suitable standard or specifications.

[0108] The various systems and / or devices used in connection with aspects of the disclosed embodiments may comprise a variety of computing devices and / or systems, including any computing system or systems suitable for implementing the systems and methods disclosed herein. For example, the connected devices and / or systems may include a variety of computing devices and systems, including laptop computer systems, desktop computer systems, server computer systems, distributed computer systems, smartphones, tablet computers, etc.

[0109] In certain embodiments, the systems and / or devices may comprise at least one processor system configured to execute instructions stored on an associated non-transitory computer-readable storage medium. As discussed in more detail below, systems used in connection with implementing various aspects of the disclosed embodiments may further comprise a secure processing unit ("secure processing unit, SPU") configured to perform sensitive operations such as trusted credential and / or key management, cryptographic operations, secure policy management, and / or other aspects of the systems and methods disclosed herein. In some embodiments, the secure processing unit may provide and / or otherwise implement a TEE. The systems and / or devices may further comprise software and / or hardware configured to enable electronic communication of information between the devices and / or systems over a network using any suitable communication technology and / or standard.

[0110] As illustrated in FIG. 5 , the exemplary system 500 may include a processing unit 502; a system memory 504, which may include high-speed random access memory (“random access memory” (“RAM”)), non-volatile memory (“ROM”), and / or one or more bulk non-volatile non-transitory computer-readable storage media (e.g., hard disk, flash memory, etc.) for storing programs and other data for use and execution by the processing unit 502; a port 514 for interfacing with a removable memory 516, which may include one or more diskettes, portable storage media (e.g., flash memory, thumb drives, USB dongles, compact discs, DVDs, etc.) and / or other non-transitory computer-readable storage media; a network interface 506 for communicating with other systems using one or more communications technologies via one or more network connections and / or networks 508; a user interface 512, which may include a display and / or one or more input / output devices, such as, for example, a touch screen, keyboard, mouse, track pad, etc.; and one or more buses 518 for communicatively coupling the elements of the system 500.

[0111] In some embodiments, the system 500 may include an SPU 710 that is alternatively or additionally protected from tampering by users of the system 500 or other entities by utilizing secure physical and / or virtual security techniques. The SPU 510 may help to enhance security of sensitive operations such as personal information management, trusted credentials and / or key management, privacy and policy management, and other aspects of the systems and methods disclosed herein. In certain embodiments, the SPU 510 may be configured to operate within a logically secure processing domain and to protect and manipulate confidential information as described herein. In some embodiments, the SPU 510 may include an internal memory that stores executable instructions or programs configured to enable the SPU 510 to perform secure operations as described herein.

[0112] Operation of system 500 may generally be controlled by processing unit 502 and / or SPU 510, which operate by executing software instructions and programs stored in system memory 504 (and / or other computer-readable media, such as removable memory 516). System memory 504 may store various executable programs or modules for controlling operation of system 500. For example, the system memory may include an operating system ("operating system, OS") 520, which at least in part manages and coordinates system hardware resources and provides common services for the execution of various applications, and a trust and privacy management system 522 for implementing trust and privacy management functions, including protection and / or management of personal data through management and / or enforcement of associated policies. The system memory 504 may further include, without limitation, communications software 524 configured to enable, in part, communications with and by the system 500, one or more applications configured to implement various aspects of the disclosed systems and / or methods, data management, and / or EPN service modules 526, and / or other information and / or applications configured to implement embodiments and / or aspects of the systems and methods disclosed herein.

[0113] The systems and methods disclosed herein are not inherently related to any particular computer, electronic control unit, or other apparatus, but may be implemented by any suitable combination of hardware, software, and / or firmware. A software implementation may include one or more computer programs that include executable code / instructions that, when executed by a processor, cause the processor to perform a method defined at least in part by the executable instructions. The computer programs may be written in any form of programming language, including compiled or interpreted languages, and may be deployed in any form, such as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. Furthermore, the computer programs may be deployed to be executed on one computer or on multiple computers at one site or distributed multiple sites, interconnected by a communication network.

[0114] A software embodiment may be implemented as a computer program product including a computer program and a non-transitory storage medium configured to store instructions that, when executed by a processor, are configured to cause the processor to perform a method in accordance with the instructions. In certain embodiments, the non-transitory storage medium may take any form capable of storing processor-readable instructions on the non-transitory storage medium. The non-transitory storage medium may be embodied by a compact disc, a digital video disk, a magnetic disk, a flash memory, an integrated circuit, or any other non-transitory digital processing apparatus memory device.

[0115] Although the foregoing has been described in some detail for clarity, it will be apparent that certain changes and modifications may be made without departing from the principles of the present invention. For example, it will be understood that several modifications may be made to the various embodiments, systems, services, and / or components presented in connection with the drawings and / or associated description within the scope of the body of work of the present invention, and that the examples presented in the drawings and described herein are provided for purposes of illustration and description, not limitation. It is further noted that there are many alternative ways of implementing both the systems and methods described herein. Thus, the present embodiment should be considered as illustrative and not limiting, and embodiments of the present invention should not be limited to the details given herein, but may be modified within the scope of the appended claims and their equivalents.

Claims

1. 1. A method for managing data executed by a cloud services system including a processor and a non-transitory computer-readable storage medium storing instructions, the instructions, when executed by the processor, causing the cloud services system to perform the method, the method comprising: receiving a device command request from an application associated with a user over a first trusted network connection, the device command request including a requestor identification, a connected device identification, and an indication of a requested device action; issuing an access authorization query to an identity and access management service, the access authorization query including the requestor identity information; receiving a response from the identity and access management service in response to the access authorization query, the response validating the requestor identity and providing at least one authority associated with controlling at least one operation of a connected device associated with the connected device identity; determining, based on the at least one permission and the indication of the requested device action, that an account associated with the requestor identity is authorized to perform the requested device action; issuing a first explicit private network key query to an explicit private network service over a second trusted network connection, the query including the connecting device identification; receiving, from the explicit private network service in response to the first explicit private network key query, a first session key associated with a connected device associated with the connected device identification; generating a connection device command, the connection device command including performing at least one cryptographic operation using the first session key; sending the connected device command to the connected device over an untrusted network connection.

2. The method of claim 1 , wherein the requestor identifier comprises identification information associated with the user.

3. The method of claim 1 , wherein the requestor identifier comprises identification information associated with the application.

4. The method of claim 1 , wherein the requestor identifier comprises an identification associated with a system executing the application.

5. The method of claim 1 , wherein the requestor identifier comprises an access token.

6. The method of claim 5 , wherein the requestor identifier is issued by the identity and access management service to a system running the application.

7. The method of claim 1 , wherein the first session key comprises a device session key.

8. The method of claim 1 , wherein the first session key comprises a group session key.

9. 10. The method of claim 1, wherein the connected device comprises one or more of a computer system, a smartphone, a tablet computing system, a security system, a vehicle infotainment system, a streaming media device, a gaming device, an entertainment system, a networked lock, a connected thermostat, a connected furnace, a connected air conditioning system, an irrigation system, a water control system, a pump system, a utility meter, a network gateway, an activity sensor, a home alarm, a connected appliance, a connected vehicle, a mobile communications device, a wind turbine system, a solar panel system, and an industrial manufacturing control system.

10. The method of claim 1 , wherein the cryptographic operation includes encrypting the connection device command with the first session key.

11. 2. The method of claim 1, wherein the cryptographic operation includes cryptographically signing at least a portion of the connection device command with the first session key.

12. 10. The method of claim 1, further comprising receiving a command acknowledgment from the connected device over an untrusted network connection indicating that the connected device performed the requested device action.

13. 13. The method of claim 12, further comprising issuing a second explicit private network key query to the explicit private network service over the second trusted network connection, the query including the connecting device identification information.

14. 14. The method of claim 13, further comprising receiving, from the explicit private network service in response to the second explicit private network key query, a second session key associated with the connected device associated with the connected device identification.

15. 15. The method of claim 14, wherein the first session key and the second session key are the same session key.

16. 16. The method of claim 15, further comprising verifying the command acknowledgment using the second session key.

Images