Patent Publication Number: US-10778659-B2

Title: System and method for protecting communications

Description:
CROSS REFERENCE TO RELATED APPLICATION 
     The present application is a continuation-in-part of U.S. patent application Ser. No. 15/115,209, filed on Jul. 28, 2016, resulting from the national stage entry of PCT/US15/13433, filed on Jan. 29, 2015, which in turn claims the benefit of U.S. provisional patent application Ser. No. 61/932,936, filed Jan. 29, 2014, entitled “Secured Invisible Private Network” and U.S. provisional patent application Ser. No. 62/022,540, filed Jul. 9, 2014, entitled “Secured Invisible Private Network.” The present application is also a continuation-in-part of U.S. patent application Ser. No. 15/136,641, filed on Apr. 22, 2016, which is a continuation of U.S. patent application Ser. No. 13/480,057, filed on May 24, 2012. Each of the aforementioned patent applications are incorporated herein by reference in their entireties for all purposes. 
    
    
     FIELD OF INVENTION 
     The present application relates to enterprise device and Internet of Things applications, systems and methods, and also relates to network communications for the same. 
     BACKGROUND 
     The Internet of Things (“IoT”) generally refers to a system of devices capable of communicating over a network, including the communications of data over the network. The devices can include everyday objects such as thermostat systems, door locks, faucets, washers, dryers, lamps, kitchen appliances, automobiles, as well as enterprise devices such as printers, routers, mobile phones and any other device able to connect to any type of network. Network communications for such devices may be used to facilitate enterprise or IoT device initialization, automation, data capture, security, providing alerts, personalization of settings, and other objectives. 
     In IoT communications, lack of data security as data flows between user devices presents problems when protecting users, user devices, networks, and enterprises. The primary issues often relate to communication security and integrity, particularly as additional IoT devices are added to the network and modifications are made to the local system. In addition to protection of data, communications security also refers to a wide range of applications including communications control, session initiation, and network monitoring. In addition to communications between devices, or data in transit protection, securing the devices themselves, such that the sender and receiver in a given communication are validated, is critical to overall protection. 
     Numerous prior solutions have attempted to improve upon IoT network communications, device, and data security. However, despite these attempts, deficiencies still persist. These prior solutions generally relate to point-to-point communications protection, communication management, and network defense. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       For a detailed description of exemplary embodiments of the disclosure, reference will now be made to the accompanying drawings, in which: 
         FIG. 1  shows examples of packet types in accordance with various embodiments; 
         FIG. 2  shows a block diagram of a system and device in accordance with various embodiments; 
         FIG. 3  shows a block diagram of a system in accordance with various embodiments; 
         FIG. 4  shows a block diagram of an exemplary packet pointer implementation in accordance with various embodiments; 
         FIGS. 5-7  show exemplary encryption schemes in accordance with various embodiments; 
         FIGS. 8-10  show exemplary encryption modulation schemes in accordance with various embodiments; 
         FIGS. 11-15  show exemplary block diagrams of a virtual communications kernel in accordance with various embodiments; 
         FIG. 16  shows a block diagram of an operation manager in accordance with various embodiments; 
         FIGS. 17-19  show exemplary user devices in accordance with various embodiments; 
         FIGS. 20A and 20B  demonstrate in-band versus out-of-band session initiation in accordance with various embodiments; 
         FIGS. 21-24  show various exemplary device authentication schemes in accordance with various embodiments; 
         FIG. 25  shows a block diagram of an authentication client in accordance with various embodiments; 
         FIG. 26  demonstrates an example communication control list in accordance with various embodiments; 
         FIGS. 27A and 27B  show examples of out-of-band session initiation in accordance with various embodiments; 
         FIG. 28  shows a block diagram of a multi-level authentication scheme in accordance with various embodiments; 
         FIG. 29  shows an exemplary block diagram of out-of-band session initiation in accordance with various embodiments; 
         FIGS. 30A and 30B  show exemplary open and partially open systems in accordance with various embodiments; 
         FIGS. 31-32  show exemplary block diagrams of a system including a virtual communications kernel in accordance with various embodiments; 
         FIG. 33  shows an exemplary closed system in accordance with various embodiments; 
         FIGS. 34-35  show exemplary cloud-based communication systems in accordance with various embodiments; 
         FIG. 36  shows a communication system in accordance with various embodiments; 
         FIGS. 37-38  show a redirection scheme in accordance with various embodiments; 
         FIG. 39  shows an exemplary accounting system in accordance with various embodiments; 
         FIGS. 40-41B  show exemplary super peers in accordance with various embodiments; 
         FIG. 42  shows another example of a virtual communications kernel in accordance with various embodiments; 
         FIGS. 43A and 43B  show an exemplary communication community in accordance with various embodiments; 
         FIG. 44  shows an exemplary enterprise communication system in accordance with various embodiments; 
         FIG. 45  shows an exemplary local IoT system architecture in accordance with embodiments of the present disclosure; 
         FIG. 46  shows another exemplary local system and communication protocol in accordance with embodiments of the present disclosure; 
         FIG. 47  shows another exemplary local system and communication protocol in accordance with embodiments of the present disclosure; 
         FIG. 48  shows an exemplary flow chart diagram for encryption of data in accordance with embodiments of the present disclosure; 
         FIG. 49A  shows an example of pre-boot and device agent communication flow in accordance with embodiments of the present disclosure; 
         FIG. 49B  shows a conceptual example of how secure boot loading may occur; 
         FIG. 50  shows an exemplary device agent data packet structure in accordance with embodiments of the present disclosure; 
         FIG. 51A  shows an exemplary workflow diagram in accordance with embodiments of the present disclosure; 
         FIG. 51B  shows a system overview in accordance with embodiments of the present disclosure; 
         FIGS. 52A-60E  show various exemplary workflows and flow chart diagrams in accordance with embodiments of the present disclosure; 
         FIGS. 60F-60G  illustrate various communication flow diagrams for policies and application data in accordance with embodiments of the present disclosure; 
         FIGS. 61-63  show various exemplary workflows and flow chart diagrams in accordance with embodiments of the present disclosure; 
         FIG. 64  illustrates a conceptual overview of the system in accordance with embodiments of the present disclosure further comprising nested local domain controllers; 
         FIG. 65  illustrates a schematic view of the system in accordance with embodiments of the present disclosure further illustrating cascading remediation; 
         FIG. 66  shows a conceptual diagram of the system in accordance with embodiments of the present disclosure further comprising logging, threat analytics and remediation; 
         FIGS. 67A-D  shows views of physical devices in accordance with embodiments of the present disclosure in different managed profiles; 
         FIG. 68  shows the system in accordance with embodiments of the present disclosure further demonstrating how a secure BIOS can overcome current BIOS hacking issues; 
         FIG. 69  shows the system in accordance with embodiments of the present disclosure further illustrating the logical location of the virtual communications kernel; 
         FIG. 70  illustrates the system in accordance with embodiments of the present disclosure further comprising a protected BIOS; 
         FIG. 71  provides an enhancement in certain embodiments wherein the virtual communication kernel  210  is implemented in any of the manners described in connection with  FIGS. 1-70  outside of a BIOS; and 
         FIG. 72  provides an enhancement in certain embodiments wherein the virtual communication kernel  210  is implemented as a protected BIOS. 
     
    
    
     NOTATION AND NOMENCLATURE 
     Certain terms are used throughout the following description and claims to refer to particular system components. As one skilled in the art will appreciate, companies may refer to a component by different names. This document does not intend to distinguish between components that differ in name but not function. In the following disclosure and in the claims, the terms “including” and “comprising” are used in an open-ended fashion, and thus should be interpreted to mean “including, but not limited to . . . .” Also, the term “couple” or “couples” is intended to mean either an indirect or direct connection. When used in a mechanical context, if a first component couples or is coupled to a second component, the connection between the components may be through a direct engagement of the two components, or through an indirect connection that is accomplished via other intermediate components, devices and/or connections. In addition, when used in an electrical context, if a first device couples to a second device, that connection may be through a direct electrical connection, or through an indirect electrical connection via other devices and connections. Connections can occur in a unidirectional, bidirectional or variable directional manner over all known means of network connectivity. 
     As used herein, the term “user” refers to a uniquely identifiable construct within a system that is able to perform an action within the system. This action is not limited in scope and can include such things as create, read, update, delete (CRUD) options, transport, transformation, communications and so forth. For example, a “user” is not limited to a human being, but also includes processes, services, and other such subsystems and code that can be assigned unique identifiers. Thus, a user differs from a unique option such as a row identifier in a database table, which is unable to take any action on the system. In some instances, a user refers to a logical construct such as a user of a virtual machine running within the context of a physical device. In this instance, the virtual user is a version of the user mapping of the application hosting the virtual machine. 
     As used herein, the general term “device” refers to either a physical device (or group of physical devices) or a virtual machine or device. A physical device generally refers to the physical and software resources required to run an operating system and supporting software. A virtual machine generally refers to an emulation of a computer system, which may be carried out by a physical device or a collection of physical devices acting towards one logical purpose. Grid computing and clustered servers are examples of multiple devices working towards one logical purpose. 
     As used herein, the terms “user device” and “active user device” refer to the logical intersection of a device and a user. Users and devices may have a many-to-many relationship and thus multiple user devices may exist within a given device or for a given user at any one time. 
     As used herein, the terms “Internet of Things” and “IoT” generally refer to a system of devices capable of communicating over a network, including the communications of data over the network. An “IoT device” may include everyday objects such as thermostat systems, door locks, faucets, washers, dryers, lamps, kitchen appliances, automobiles, as well as enterprise devices such as printers, routers, mobile phones and any other device able to connect to any type of network. 
     As used herein, the term “platform” refers to a grouping of similar devices. Devices may be grouped based on the type of operating system used, the type of device itself (e.g., secured/unsecure; desktop/laptop/mobile; client/server; peer/super peer; or old/new), or another distinction that identifies devices in a given system either by its presence and variability among devices or by it lack of presence in some subset of devices. Thus, as used herein, the term “cross-platform” as in “cross-platform communication” refers to devices of two different platforms that communicate with one another; such a cross-platform system may be referred to as a hybrid system. 
     Finally, as used herein, the term “operation” or “performing an operation” refers to a packet-modifying operation such as encrypting the packet, replacing the packet with an alternate packet, deleting the packet, cloning the packet, replacing the packet with a packet pointer, and the like. Performing an operation on a packet may be restricted to a base datagram and may exclude to the modification of header fields. 
     DETAILED DESCRIPTION 
     The following disclosure is directed to various embodiments of the disclosure. Although one or more of these embodiments may be preferred, the embodiments disclosed should not be interpreted, or otherwise used, as limiting the scope of the disclosure, including the claims. In addition, one skilled in the art will understand that the following description has broad application, and the disclosure of any embodiment is meant only to be exemplary of that embodiment, and not intended to intimate that the scope of the disclosure, including the claims, is limited to that embodiment. 
     Internet Protocol Security (IPsec) is a protocol suite for securing Internet Protocol (IP) communications by authenticating and encrypting each IP packet of a communication session. There are two main modes for IPsec: tunneling mode, which is used for virtual private network (VPN) support and transport mode, which is used for point-to-point communications. However, as a result of differences in header formatting among IPsec proponents, cross-platform, point-to-point security is not possible. This lack of cross-platform support renders IPsec—unable to protect communications in a hybrid environment such as over the Internet. 
     Due to the dependence and location of IPsec within the IP communication layer of an operating system, IPsec suffers limitations. First, IPsec cannot encrypt data from a given port and then place the encrypted packets back on the same port. Rather, IPsec uses a standard set of well-known ports, which provides assailants with predetermined communications routes to monitor. The use of static ports also opens widely-recognized ports in firewalls and operating systems when optional-on IPsec security is not running. 
     Further, because IPsec is tightly coupled to the operating system, broad reaching updates to its functionality are also overly burdensome. IPsec uses a security algorithm that is provided by a given operating system and this is not an option that can be easily updated. As such, cross-system compatibility forces IPsec communications to rely on security features for numerous years or even decades at a time. The rate at which security algorithms become vulnerable is much faster, and thus the protection afforded by IPsec cannot keep up with that pace. 
     IPsec also encrypts an entire packet of data, which can introduce issues when dealing with maximum transmission unit (MTU) limitations. For this reason, most multimedia transmissions are unable to use IPsec to secure UDP packets with very large datagrams. IPsec is further restricted by what is considered acceptable by lower communication layers such as TCP and UDP. These limitations restrict the flexibility of IPsec as far as what encryption options can be applied and how those options can be varied. That is, with IPsec, only one algorithm can be used, which is determined by the operating system, and that algorithm has to be applied to all packets across all secured communication streams. 
     IPsec also suffers limitations given its location in the communications stack such that many types of communication result in a failure for IPsec to process data properly. As one example, certain communications, such as WiFi, satellite, BlueTooth and microwave do not guarantee the proper order of lower level, Ethernet, packets to the upper level IP layer. As such, lower level packets are normally cached in the IP layer by an operating system and then re-assembled once all of the lower level packets arrive. For IPsec, however, this reconfiguration is not possible due to the whole packet encryption approach and, therefore, IPsec fails to run over these types of communications. 
     What is needed, and is provided by various embodiments of the present disclosure, is an adaptable framework that removes operating system restrictions from network communications. Such a system should provide encryption options, isolate the network from the operating system, and yet simultaneously be transparent to the operating system in order to avoid any interaction issues, for example with applications executing in the operating system environment. 
     Although IPsec transport mode was intended to secure point-to-point communications, it was never intended to manage communications. This area is largely defined by what are termed “Triple A Services” or authentication, authorization, and accounting. Authentication refers to the concept of taking a first class entity and verifying the identity of the entity. In some systems, such as Lightweight Directory Access Protocol (LDAP), the first class entity is a user. In other systems, such as a Unified Computing System (UCS), a user device is a first-class member. Authorization is dependent on an authentication entity establishing what resources an entity can access and, optionally, what interactions an entity is allowed to have with each resource. Finally, accounting refers to the process of measuring resource access from the perspective of the resource provider. For example a mobile gateway might record the amount of time it allows a mobile user device to access a given VOIP connection. 
     In modern environments, shortcomings in each of these systems cause significant issues. For example, there is no method employed in these systems to authenticate a second class member or even add a new type of first class member option. This results in situations where a first class member requiring more restricted access is unable to be properly restricted. As one example, an executive may be given the same access rights to sensitive data regardless of whether that executive logs in from a central work computer or from an insecure phone at some remote location, which creates a higher likelihood of a security breach. 
     In accordance with certain embodiments, an adaptable, variable first class membership authentication solution is provided that allows for n number of first class members to be combined together as required to accomplish the level of granularity required. This system is able to extend current LDAP/UCS solutions at differing levels and provide control of such authentication to a given network as needed. To this end, an authentication system disclosed herein is able to include first class members from an existing LDAP system and extend its functionality by adding first class members from either its own system or from another LDAP system, and thus utilize a different type of first class member. While authorization schemes are limited given their dependence on authentication, a larger issue is a lack of communications control. In modern paradigms, even if a user on a given user device has no access to any resources on another user device, the two user devices can freely communicate with one another. This uncontrolled communication can create conduits for malicious activity such as, for example, the spread of malware within a network. 
     In addition to providing authorization by the first class member combinations described previously, various embodiments of the present disclosure allow authorization systems to be expanded to include communications control. For example, such systems differentially control with whom members interact, how they interact, when they interact and, amongst other things, how much and/or type of data is exchanged. Given the flexibility in first class membership, these interactions may occur through any number of entities including users, user devices, applications, or some combination thereof. Prior solutions do not address these needs for either authentication or authorization. 
     Turning now to accounting, prior solutions are largely one-sided with little ability to guarantee delivery. In accounting systems, a resource provider commonly reports to an accounting server that the provider is providing a given resource and subsequently the resource provider reports when that resource access is terminated. While there may be optional intermediate updating, information is not provided by the resource consumer sufficient to validate the use of a given resource. One example of this issue relates to Quality of Service (QoS), for example, in relation to multimedia streaming. QoS is generally equated with bandwidth; thus a given user who desires improved QoS may request a better QoS, which results in an indirect request for increased bandwidth. A gateway may approve such a request and thus provide this additional bandwidth, along with reporting this increase in bandwidth to an accounting server. However, in certain situations an increase in bandwidth may not actually improve the user&#39;s QoS. Problems such as network saturation, multimedia provider limitations, or even user device processing speeds may serve as a bottleneck that is not solved by simply providing more bandwidth. 
     In these cases, the user has requested a better QoS and the accounting server will bill the user for the increased QoS based on the gateway reporting, however the user never actually receives the requested enhanced QoS experience. Without resource consumer-side account reporting, there is no way to verify the actual user QoS; this deficiency in reporting can lead to ongoing issues. In accordance with certain embodiments of the present disclosure, consumer-side accounting is provided where the resource consumer provides reporting to the accounting server based on what is actually received at the consumer, rather than what a gateway assumes is the case at the consumer. 
     In modern computing, networks focus on defending themselves as much as possible, but rarely attempt to directly respond to ongoing attacks in real time. Limitations in the prior art prevent networks from turning attacks on the attackers, distributing resource overload attempts (for example countering distributed denial of service (“DDoS”) attacks) across sufficient on demand resources to overcome a challenge and so forth. One challenge facing networks is that any attempted solution is bound to the operating system and that operating system&#39;s associated communication layers. These layers provide readable indicators, for example a network hop and/or forwarding address, or use an exploitable initiation process such as a TCP handshake that prevents many types of counter-intrusion responses. 
     Considering these limitations, most network defense systems focus instead on intrusion detection response efforts. For example, these efforts attempt to minimize lag between an initial intrusion and a subsequent response and adaptation to that network&#39;s defense. One issue with this approach is that an attack always gets in and does some level of damage before it is blocked. The attackers are never directly confronted, although subsequent identification efforts may be taken, and these attacker&#39;s efforts are always successful to some degree. Response times to a given intrusion are often measured in weeks and months, which can exacerbate the damage. 
     In accordance with various embodiments of the present disclosure, network defense is provided that is proactive and prevents intrusion, as much as possible, before an attack occurs. For example, if a given member of a network is compromised, network defense mitigates the damage by isolating the infected member and preventing the dissemination of a given attack vector. If an active intrusion effort is detected, network defense responds to this attack in a manner that is transparent to the would-be intruders. Thus, in certain embodiments the response to an attack effort is beyond the purview of the host operating system while still residing within the targeted device. 
     As explained above, and as will be appreciated by one of ordinary skill in the art, point-to-point communications security suffers from significant issues. The main option available today, IPsec, suffers numerous limitations due to its reliance and location within an operating system. One such limitation is an inability to unravel a given packet, encrypt the core datagram and then rewind the packet back to its original format, aside from any descriptive field changes such as data length. Rather, as shown in  FIG. 1 , IPsec encapsulates the entire packet (i.e., original IP header  106  and IP body  108 , which includes a base datagram  110 ) and adds its own Authentication Header  104  onto the top of the IP packet  106 ,  108 ,  110 . This results in both a highly visible header and one that, despite a standard to the contrary, can be implemented in multiple manners. 
     The IPsec standard has at least two main supporters that have created incompatible versions of IPsec. As a result, implementing security in a cross-platform manner is not possible. As yet another issue, IPsec fails to enable routing for current version of IP traffic. In order to protect sensitive data within the visible headers noted above, IPsec transport mode generates a hash of the entire message, which prevents any changes. Although secure, this feature precludes the use of Network Address Translation (NAT) options, which relegates IPsec transport mode to private LANs as opposed to open WANs such as the Internet. This is similar to other approaches, such as the 802.11x standard, wherein entire packets are encrypted and devices, such as routers, have to be specially configured to handle this malformed traffic. 
     In accordance with various embodiments of the present disclosure, a virtual embedded security kernel or virtual communications kernel is provided on a user device that allows packets to be encrypted, modified, or otherwise operated on in a way that is not readily apparent to an operating system of that user device. As such, no modification of the operating system or any applications executing on the user device is needed to take advantage of the capabilities of the virtual communications kernel. Further, modifications to the virtual communications kernel itself, or to operations carried out by the virtual communications kernel (e.g., modifying an encryption scheme implemented by the virtual communications kernel) may be performed through a simple update procedure, and may be tailored to a user&#39;s desires on a case-by-case basis. 
     As shown in  FIG. 1 , a virtualized packet  120  includes the same IP packet  106 ,  108  that would be subsumed using IPsec. However, unlike the IPSec transport packet  100 , the virtualized packet  120  includes only a modified base datagram, referred to as a virtualized datagram  124 . Further, it should be understood that certain pre-existing field values in the IP header  106 , for example, may be updated as long as the original packet header structure remains intact. This figure is exemplary and should not be construed as limiting the scope of the present disclosure to IP traffic. In fact, any form of communications that provides a core datagram, or even just a datagram, is within the scope of the present disclosure. In the example of  FIG. 1 , the original IP header  106  includes fields such as time to live and packet length, which can be optionally updated but, outside of those fields, the IP packet itself remains structurally intact. 
     In accordance with various embodiments, the virtual communications kernel is logically situated above a physical layer (e.g., a physical layer of the Open Systems Interconnect (OSI) stack) but below all other layers. As a data packet travels from an application through the higher layers, the data packet can be inspected and, optionally, intercepted by the virtual communications kernel prior to reaching the physical layer, for example the miniport driver of a network interface card (NIC). The virtual communications kernel may then perform one or more operations on the data packet, the details of which will be explained further below, while any processing of the header of the data packet can be separate and distinct from the operations performed on the data packet. By leaving the header in its original format (aside from modifying standard fields such as data length, for example), the present disclosure overcomes routing and addressing challenges. 
     A header can be any part of a packet of data that is available for general inspection. For certain protocols such as TCP, UDP, and IP, a header is typically considered to be a prefix that contains overall information about the packet such as, but not limited to, addressing information, time to live, and IP version. Addressing information can include source address, destination address, and intermediate addresses such as those used for proxy or static routing efforts. Different protocols, for example IPv6, allow headers to be nested within one another in order to enable a richer feature set. All such options are within the scope of the present invention. 
     In some embodiments, the virtual communications kernel is placed directed above a NIC card, in other embodiments, the virtual communications kernel runs within a separate process space defined by options such as a BIOS pre-boot operation or a designated processor option akin to a GPU space. Certain embodiments might implement the virtual communications kernel as an application with access to packets at a low level of communications. In these embodiments, such an application might use options such as Microsoft&#39;s Network Driver Interface Specification (NDIS) or Linux Netfilter to access lower level packets. These placements enable the virtual communication layer to overcome limitations with the type of protocol by working at the lowest level of packets guaranteed to be complete by the lower levels of a device. Therefore, in the cases of lower level operations, at times referred to as communication drivers, the packets from communication types such as Bluetooth, WiFi, microwave and so forth, are always provided to the virtual communication kernel completely constructed. This enables the virtual communication layer to operate across types of communications without restriction. 
     In certain embodiments, the virtual communication kernel might be forced to cache subparts of the lower level packets until these packets are fully-constructed. This embodiment, for example, might occur in a security kernel implementation on a chip residing outside of a given operating system. In these embodiments, the lower level layers need to provide a header value denoting the original order and embed those values into the lower level packets. The virtual communications kernel is then able to cache the subparts, request missing subparts from the lower level layers from the sending device, and reconstruct the packets as needed. 
     Turning now to  FIG. 2 , a system  200  is shown in accordance with various embodiments of the present disclosure. The system  200  includes a device  202  coupled to a network  214 . The device  202  may include any one of a variety of computing devices, such as a desktop, a laptop, a smartphone, and the like, which is configured to communicate with one or more other devices over the network  214 . The system  200  may include many such devices  202  in communication with one another over the network  214 . The network  214  may be a wired network or a wireless network and may comprise networks such as a local area network (LAN), a wide area network (WAN), the Internet, and the like. 
     The device  202  includes an operating system  204  within which their existing a logical known space  206 . For simplicity, components of the device  202  are not shown, but it should be understood that the device  202  may include various components such as memory, hardware storage, a user input device  202 , a display device  202 , a file system, various communication and device  202  drivers, and the like. The operating system  204  and various applications  208   a ,  208   b  may be executed within the operating system known space  206 . Known space  206  refers to the region of the operating system where processes are controlled, either directly or indirectly, by operating system rules and limitations. This known space  206  is a logical construct that related most directly to the rules and restrictions of the OSI model and how that model is implemented within a given operating system  204 . The virtual communications kernel  210 , which may be instantiated as part of the operating system  204  is not part of the operating system known space  206 . The applications  208   a ,  208   b  may generate data or serve as a conduit for data (e.g., that received from an end user device  202 ) to be transmitted over the network  214 . 
     In accordance with various embodiments, a virtual communications kernel  210  is logically positioned between the higher layers where the operating system  204  and associated applications  208   a ,  208   b  are executed and a physical layer  212 . The higher layers may comprise layers of the OSI model including the application layer, the presentation layer, the session layer, the transport layer, and the network layer. Below the virtual communications kernel  210 , the physical layers  212  may comprise the data link and physical layers for example the miniport driver for a network interface card (NIC). Other embodiments might not use OSI, such as a Real Time Operating System (RTOS), or an operating system at all, such as in lower level IoT sensors. In these latter embodiments, the upper levels are generally defined as any applications, processes or functions collecting or performing operations on data to be transmitted. Lower level layers are generally defined as those physical or virtual processes involved in the transmission and reception of information over a network. The virtual communications kernel can, itself, comprise the totality of the lower levels in certain embodiments, the upper levels in other embodiments or both. 
     The virtual communications kernel  210  may be initialized as an additional layer within the confines of the operating system  204  or this layer may be initialized outside the scope of the operating system  204 . In the latter scenario, a BIOS pre-boot loading sequence may initialize the virtual communications kernel  210  after the physical layers  212  have been established but independent of the activation of the operating system  204 . 
     The virtual communications kernel  210  intercepts communications packets  302 , shown in  FIG. 3 , which the upper levels, in this case the Operating System,  204  and/or the applications  208  send to the network  214 , which are then processed in accordance with various embodiments. After processing, depending on the embodiment, the virtual communications kernel  210  places the virtualized packet  120  back into the original data stream where the packet  120  is then sent to the physical layers  212  and to the network  214 . 
     Referring to the logical location of the disclosed virtual communications kernel  210 , it is noted that IPv4 and IPv6 are constructed at a level logically situated above the virtual communications kernel  210 . Therefore, in embodiments where a packet is deconstructed, the base datagram  110  can be altered or operated on and then the packet can be rebuilt and the original header structure reapplied. That header construct may be a simple IPv4 or a more complex, possibly nested, IPv6 header structure, or some other packet header. Header fields that may be updated are existing fields within the general header construct such as time to live, addressing information, and/or packet size. Considering the commonality of the outer header fields for IPv6 and the IPv4 header fields, for example, the same header operations can be applied to packets regardless of the version of IP. Differential operations might also be utilized and this IP version-agnostic capability is presented for sake of clarity on the logical position of the virtual communications kernel. IPv4 and IPv6 are presented as common examples of communications packets and are not restrictive in any manner. Other embodiments, as one example, can process Internetwork Packet Exchange/Sequence Packet Exchange (IPX/SPX) packets most commonly found in Novell Netware operating systems. 
     To the external world, the packet operated upon in accordance with the present disclosure has the same structure as the original packet. As explained above, the virtual communications kernel  210  resides below the non-physical OSI layers, and, as such, the same ports originally used can be used to send the encrypted or otherwise operated-on packets to the physical layers  212 . Subsequently, the virtual communications kernel  210  transmits the modified data packet to the physical layer  212 , at which point the data packet may be transmitted across a network  214 . As will be explained in further detail below, when a data packet is received from the network  214  via the physical layer  212 , the virtual communications kernel  210  may operate similarly to “undo” any operation that has been performed on the data packet before transmitting the packet to the upper level layers  204 . 
     In this way, the existence of the virtual communications kernel  210  is transparent to the upper level layers  204  of the device  202 . Further, the virtual communications kernel  210  serves to isolate the upper level layers  204  from a network  214  over which communications may be sent. The present disclosure also addresses synchronization of packets between two devices  202  in a communication stream where each device  202  implements various embodiments of the present disclosure. 
     Separately, the present disclosure addresses synchronization of packets being sent to and from the upper level layers  204 . Referring to  FIGS. 2 and 3 , as one non-limiting example, assume Computer A (e.g., device  202   a ) sends a communications packet  302  with a sequence number of 15 to its local virtual communications kernel  210 . Further, assume that the operation process carried out by the virtual communications kernel  210  comprises an encryption process that creates an odd number of packets, such that the packet number expected by a virtual communications kernel  210  on another device (e.g., device  202   b ) was  22 . An embodiment of the present disclosure maps the communications packet  302  (with sequence number  15 ) and the virtualized packet  120  (sequence number starting at # 22 ) on both sides of the communication stream. This mapping feature results in the ability to combine multiple OS packets  302  into one virtualized packet  120  or, conversely as shown in  FIG. 3 , to extrapolate one communications packet  302  to numerous virtualized packets  120 . The communication between two virtual communications kernels  210  over a network  214  is independent of the communications between an upper level layers  204  and a virtual communications kernel  210 . By synchronizing packets, the virtual communications kernels  210  are able to achieve transparent isolation and remain invisible to the upper level layers  204  and any applications executing on a device  202 . The operating systems  204  are effectively communicating directly with one another while the virtual communications kernel  210  is able to make any modifications without impact to that upper level layers  204  level communication session. 
     Many embodiments will incur negative consequences to the splitting of upper level communications packets  302  into numerous packets  302  at a given level such as described in the example above. To this end, many protocols, such as UDP, enable “over-stuffing” packets in order to avoid this issue. The virtual communication kernel  210 , in certain embodiments may interact with the upper level layers  204  to configure options in a communications stack to avoid such issues. As one example, the virtual communications kernel  210  might configure the TCP Window Size in the upper level layers  204  to enable a buffer for modifying the base datagram  110 . In such an embodiment, the window size might be decreased by a certain amount such that modifying the base datagram  110  does not result in one communications packet  302  being divided into two or more packets. 
     In some embodiments, the virtual communications kernel  210  intercepts a communications packet  302  and modifies the base datagram  110  within that communications packet  302 . In order to accomplish this process, the virtual communications kernel  210  breaks the communications packet  302  down to its core datagram  110 . This datagram  110  may exist at an application layer, at a transport layer, or any layer in between. At the virtual communications kernel  210 , the packet breakdown (also referred to herein as “unwinding” the packet) continues until the core datagram  110  has been uncovered. It should be noted that “breakdown” or “unwinding” can be equated to extraction or replace functions in certain embodiments such that a previously known, configurable, set of offsets can be leveraged to remove or isolate the payload from a serial string of data found within a packet. In these cases, the packet is not unwound as much as a part of the serialized data, text or binary, is modified either in the serialized data or by removing the subset, performing none or more of a possible number of operations and then re-inserting the subset into the serialized data. 
     At that point an operation on the core datagram  110  may be performed, resulting in a virtualized datagram  124 . As one example, an embodiment may encrypt the datagram  110  using one or more algorithms according to a range of rules, described in detail below. Another example operation is replacing all or part of the core datagram  110  with a pointer to data shared across devices  202 , for example to reduce the size of duplicate packets being transmitted between devices  202 . In other embodiments, the core datagram  110  might be captured and redirected—either individually or as a stream—to a separate location from the intended destination for that communications packet  302 . In any case, an encryption operation may be layered on top of other operations. That is, in the latter described copying embodiments, a related or independent single or set of encryption approaches may be applied as compared to the OS data packet  302 . Streams might be comprised of entire communications packets  302  or core datagrams  110  along with optional header values or both. 
     Once the operation on the core datagram  110  is complete, the virtual communications kernel  210  optionally builds the virtualized packet  120  such that it again resembles the original communications packet  302 . For example, the initial header or addressing information for the data packet may be re-used with only standard fields, such as CRC values and data lengths, being modified. The operation performed on the core datagram  110  is not also performed on the data packet&#39;s initial header. In some embodiments, other standard fields such as proxy server or even source and destination IP address fields are utilized to make additional modifications, but the overall structure of the header remains unchanged after the virtualized packet  120  has been rebuilt. Depending on rules, such as intercepting malformed or suspicious packets, found in a number of optional locations not restricted to policies, embedded logic of configuration files, some embodiments may not reconstruct the packet and, instead, remove the communication packet  302  from the overall communications stack. 
     Other operations may be performed on the communications packet  302  that do not require a directly interacting with the base datagram  110  of the communications packet  302 . Examples of such operations include cloning the packet, redirecting a packet, filtering packets, and the like. The present disclosure is not limited to a particular type of operation that is ultimately performed on the communications packet  302  or the core datagram  110 ; rather, any operation performed within the functionality of the disclosed virtual communications kernel  210  is within the scope of the present disclosure. 
     Certain exemplary embodiments are directed to packet pointer security. These embodiments include an optional operation that may be performed by itself or as part of a large series of operations to be described more fully below. The premise of packet pointer security is that, at the level of a base datagram  110 , there exist common sequences of bytes across all packets of information. It is not guaranteed that a given sequence exists in all packets, although that may be the case in certain instances; however, common patterns of bytes or bits of data exist within a network of communication streams. Based on that premise, extracting common patterns would allow those patterns to be replaced with pointers, which both reduces communications size and further secures data being transmitted. 
       FIG. 4  demonstrates a packet pointer system in accordance with various embodiments. As described previously, an application  208 A transmits a communications packet  302  to another device  202 . The packet is intercepted by the virtual communications kernel  210 , which may compare the base datagram  110 , either in whole or in part, with entries in a packet pointer table  406  to determine the existence of matching patterns. The packet pointer table  406  represents a logical construct that might be, for example, implemented as a hash table, queue, memory map file, text file, in memory database, or any other such construct that enables a lookup process. The lookup process may consist of rows in a table, a series of name-value pairs, or other similar constructs such as a seed or key value to place into an algorithm. In this latter case, the key or seed value is utilized on the other end of the communications stream, in this case by device  202   b , to recreate the original pattern based on the seed or key value. 
     The virtual communications kernel  210  compares the contents of the base datagram  110  to the entries in the packet pointer table  406  and, if a match is found, the pattern in the base datagram is replaced with the lookup value&#39;s corresponding pointer. This process may continue according to optional business rules and/or until all of the entries are inspected. In some cases, the entries are organized by the size of the patterns, the date a pattern was added to the packet pointer table  406 , the popularity of a given pattern, and so forth. Business rules, for example, could force successive iterations through all entries again to create nested groups of replaced patterns such that the newly inserted pointers/name values themselves are replaced by other pointers, keys, or name values. Different types of patterns may be used to denote various levels of nesting depending on the embodiment. Thus a logical level 1 set of matches might be applied to the base datagram  110 , the next logical level to the datagram  110  after a first pass, and so forth. This enables control over the nesting and un-nesting features. 
     Once completed, the altered base datagram  110  can then be optionally encrypted by the virtual communications kernel  210  to create a virtualized datagram  124 , as explained above, and the packet itself is rebuilt to create a virtualized packet  120 . In some embodiments, any such encryption occurs first and then pattern matching is carried out. In these cases, there might be additional embodiments in which encryption occurs after the pattern matching process. This sequence of encryption, pattern matching, and optionally more encryption can be modified in subsequent embodiments and controlled through static or dynamic rules to create an additional layer of security. All such variations are within the scope of the present disclosure. 
     This virtualized packet  120 , outside of updating fields such as the data length, time to live, and CRC fields, is structurally the same as the original communications packet  302 . It should be noted that any field can have its value modified as long as the original integrity of the packet remains intact. In certain embodiments, this process can include the transparent use of intermediate, proxy servers. To accomplish this task, the virtual communications kernel  210  can modify the standard header fields, for example the Destination IP field in a TCP packet, to direct a packet to an intermediate server or node. In these embodiments dealing with TCP or UDP packets, provided as an example and not in any way restricting to those protocols, the intended IP address can be moved to another standard header field called X-Forwarded-For. This process is a standard approach, does not change the structure of the communications packet  302  and is considered to be part of this invention. 
     During processes that focus on the packet pointer system, either by cloning the base datagram  110  or by cloning the resultant virtualized packet  120 , the virtual communications kernel  210  is able to create a copy of the virtualized packet  120 . This copy would have its destination IP address field, and optionally its port and source IP fields, altered such that the packet is sent to a packet pointer security device  400  instead of the device  202   b.    
     Thus one virtualized packet  120  is sent to the device  202   b  and the other virtualized packet  120  is sent to the packet pointer security device  400 . In alternative embodiments, the receiving device  202   b  may create the clone and forward that clone to the packet pointer security device  400 . This embodiment is particularly useful when adding in resource consumer-side accounting, as this conduit could support both functions. Yet another embodiment places the packet pointer security device  400  in between the devices  202 , which mitigates the need for cloned packets. 
     The virtualized datagram  124  is optionally decrypted on the receiving devices  400  and  202   b , and then pattern matching is performed in reverse, with the name or pointer used to revert the entire or partial section of the virtualized datagram  124  back to the original set of bits or bytes. If the inserted value is a key or seed value, then a hosted algorithm is used to generate the missing data. This process continues in the reverse order of the processing for the outgoing packet described above, until the original base datagram  110  is reconstructed. In certain embodiments, this includes completely reverting all nested replacements and/or performing any subsequent decryption efforts. Once complete, the original communications packet  302  is rebuilt with all original field values replaced as needed, including expected synchronization values and correct CRC calculations. 
     Referring to the packet pointer security device  400 , the communications packet  302  is sent to a logical construct referred to as a packet pointer processor  404 . This construct may be implemented using an application, a system of hardware devices and/or applications, or another similar implementation that supports the described processes. In one embodiment, this construct consists of software that receives the incoming OS packets  302  and stores them in a storage device. The packet pointer security processor  404  includes a map reduce capability that continuously determines the best patterns to utilize before storing the results of this effort in the packet pointer storage  402 . The packet pointer storage  402  may comprise a physical database, a document repository, an in memory datagram, an XML map memory file, or any other such medium capable of storing data. 
     The packet pointer processor  404  compares the bits or bytes of data across numerous packets and obtains common patterns found within these packets. Thus, the base datagrams  110  are unwound to form conceptual lines of bits or bytes, which are then compared to one another using any combination of matching methods. For example, some embodiments might take a string in the first position and compare that string to the other strings in a set, first as a whole and then as a substring. This latter substring can be generated by taking one bit or byte of either or both ends of the first string, by creating a crawling subset, or by starting with a central minimum subset and expanding outwards. A crawling subset may be created by starting at one end with a sub string of finite length that is smaller than the whole string with a position of 0. As pattern matching progresses, the length of the substring stays the same, but the starting position of the substring increases until the entire string has been processed. Some embodiments might continue through to the end of the first string, thus producing smaller and smaller sub string lengths, whereas other embodiments might stop when the sub string includes the last bit or byte of the first string or some minimum substring size is reached. Other embodiments may crawl in reverse order and even others may start at both ends and create combinations off of the two resultant substrings. 
     Some embodiments might utilize a generational approach which supports different levels of matching patterns as described previously. Thus a given map reduce effort might be utilized to generate a logical first level of patterns. Then, the resultant datagrams, modified with the pattern-matched modifications, can be processed again to generate a logical second level of patterns and so forth. 
     In more complex cases, matching process instructions in the virtual communications kernel  210  may be included in the packet pointer table  406 . By including instructions, which can be a simple sequence number to denote the type of matching or a complex series of steps akin to BPEL commands, the matching paradigm can become more sophisticated. As one possible example, different matching techniques may be strung together such that a given pattern is only used if certain other matches occur ahead of time, or whether a certain type of encryption algorithm was used. These additional features are useful in avoiding data corruption issues, which can occur when encrypting certain patterns of data as one example. 
     Regardless of the operation performed on the base datagram  110 , after the virtual communications kernel  210  performs the operation(s), the virtual communications kernel  210  assembles the virtualized packet  120 . After the virtualized packet  120  has been assembled, the virtual communications kernel  210  forwards the virtualized packet  120  to the lower level layer  212 , which transmits the virtualized packet  120  across the network  214 . Unlike other packet security schemes, the header of the data packet remains structurally unmodified (although, as described above, certain field values, such as a data length field or CRC field, may be altered or recalculated to account for other changes to the data packet) by the virtual communications kernel  210 . That is, the original header format is maintained such that a receiving entity coupled to the network  214  recognizes the format of the packet. In certain circumstances, header fields, such as a packet length field or a cyclic redundancy check (CRC) field, are modified to reflect changes to other portions of the data packet, but the header structure itself is not otherwise operated on. In some embodiments, where the operation performed is an encryption operation, the virtual communications kernel  210  would not encrypt the header itself. 
     The virtual communications kernel  210  also may be configured to operate on certain packets while allowing other packets to pass through to the physical layer  212  without first being operated upon. For example, the virtual communications kernel  210  may perform operations on packets directed to a certain port, but does not perform operations on packets directed to ports other than the certain port. It should be appreciated that the same differentiation scheme may apply to a grouping of ports and that any field, attribute or field/offset can be utilize in any matching or filtering paradigms described in this invention. Further, in other embodiments, the virtual communications kernel  210  may perform operations on all packets to be transmitted over the network  214 . Other embodiments may apply an optional filter on any characteristic that can be attributed to a packet including, but not limited to, source/destination IP address, protocol, packet size, sending application, and so forth. This filter can be used to differentiate packets and subject certain packets to no operations or a varying set of operations based on any number of characteristics. 
     The ability to inspect, filter, and apply variable operations at the packet level therefore leads to the ability to enforce a distributed packet level firewall capability. Dynamic firewall features are covered later in this disclosure and this feature is similar to deep packet inspection firewalls, although with numerous differentiating features. Prior art deep packet inspection firewalls are most commonly implemented as separate appliances or intermediary servers situated between a possibly large number of devices on one side and a protected variable set of resources on the other side. While effective in handling packet level inspection and supporting rules to that end, deep packet inspection firewalls are limited in terms of speed and throughput. In accordance with various embodiments, packet inspection requirements are distributed to a larger number of devices, thus mitigating the speed and throughput concerns of prior art designs. Further, as will be explained, more intricate rules can be created based on a distributed enforcement model as opposed to a centralized system. 
     In accordance with various embodiments, the ability to differentially operate on packets based on various packet characteristics provides a new approach to performing encryption or other operations. Certain embodiments of the present disclosure take advantage of this feature to provide enforcement rules that apply different types of encryption at different times based on a static or dynamic series of characteristics. As shown in  FIG. 5 , the use of multiple types of encryption may be applied within the same communications channel. As shown in virtualized packet streams  500 ,  502 , the same encryption may be applied for packets flowing in either direction. Virtualized packet stream  504  demonstrates a first encryption used for packets going one way, whereas virtualized packet stream  506  demonstrates a second, different encryption used for packets going the other direction. 
     Encryption can be further changed within a given stream over time for a potential range of reasons. As one example, virtualized packet stream  508  shows a different encryption being applied on every other packet. As another example, virtualized packet stream  510  shows no encryption being applied on a random packet, namely the third packet from the left. In still other embodiments, multiple encryption schemes are applied on a single packet. The application of one of more encryption algorithms, pattern-based bit/byte swapping, encoding, or other data altering/conservation techniques to a given packet is referred to generally as an “encryption approach.” In addition to controlling encryption based on remote destination, the present disclosure enables altering encryption based on other options such as the protocol or application involved in a given communication session. For example, as shown in  FIG. 6 , disparate encryption approaches are applied to different communication streams by protocol such as email  600 , FTP  602 , or web  604  and/or by application such as chat  606  or cloud-based applications  608 . 
     Embedded rules, a configuration file, or more complex options such as BPEL may be used to determine which packets to apply which encryption approach. This capability provides for additional embodiments to support complex encryption management requirements for securing communications. While some embodiments utilize the same encryption regardless of duration, other embodiments alter the encryption approach over time, for example as time progresses in the downward direction as shown in  FIG. 7  or by amount of data processed, time of day or any other option available on the device including application and/or operating system changes, user login or other process interactions. The process of changing encryption approaches over time, or in response to changes in other factors or variables, is referred as an “encryption modulation.” 
     Some embodiments statically include such modulations as part of embedded code or a configuration file, whereas other embodiments utilize a concept referred herein as a connector pattern. Connector patterns are constructed of modulation charts, which are combinations of modulation packages, each of which contain a series of modulation sequences. These embodiments are described more fully below, beginning with a modulation sequence. 
     A modulation sequence is an instruction or command that tells the virtual communications kernel  210  to perform a given encryption approach on a packet. Packets are selected based on any characteristic of that packet or, in the case of no applied filter, the encryption approach is applied to all packets. A modulation sequence may include, as part of its encryption approach, a single operation to be applied to a matching packet or a series of operations joined together using a logical join operator such as Next, Or, And, or other operators common in process flow approaches. These operators enable primitive process flow applications at the packet level to provide optional additional levels of operations for more advanced requirements such as cloning and nested encryption 
     A modulation package is a series of modulation sequences sufficient to cover all applicable packets for a given device  202 . A modulation package may vary from one embodiment to the next, but could be required, for example, to provide at least one modulation sequence for every type of packet passing through a device  202 ; in some instances, a catchall modulation sequence may be used to ensure such compliance. Certain embodiments allow for modulation sequence overlap, such that a given packet might be processed more than once (i.e., be subject to multiple modulation sequences). In these instances, the order of modulation sequence processing can be determined in a variety of manners, such as newest/oldest modulation first, a manually entered priority number, based on type of operation, and so forth. Dynamic components such as time of day, device type, device location, and the like may be applied to turn on or off the availability of certain modulation sequences within a modulation package as well as to change priorities of those modulation sequences. This latter set of instructions may be stored as metadata with the modulation sequences within the logical modulation chart construct. Other embodiments prevent overlapping modulation sequences, but may still utilize dynamic data to determine the availability of specific sequences. 
     A modulation chart is a logical level above the modulation package. The modulation chart contains a variable number of modulation packages along with a connector pattern, which is explained in further detail below. Some embodiments include a series of modulation charts and rely on virtual communications kernel  210  processing to determine which chart to utilize. In these embodiments, determination logic may be included as embedded code in the virtual communications kernel  210 , as separate instructions sent to the virtual communications kernel  210 , as a configuration file, or some other similar data input. In all of these cases, the determination code may be static, such that the determination of a given modulation sequence or use of modulation packages can be fixed; in other embodiments, the determination code may utilize dynamic information. In the static instances, variability may still be introduced based on placement of the modulation packages within the modulation chart. As one example, a static determination code may generally state that the virtual communications kernel  210  should use the modulation package in position  1 , then the modulation package in position  2 , and so forth. The process of creating the modulation chart could therefore distribute, either randomly or according to some set of rules, the modulation packages into various logical positions for different iterations of the modulation chart. 
     In other embodiments, a connector pattern is created in which the order of transitioning from one modulation package to another is determined ahead of time.  FIG. 8  demonstrates one such conceptual example of a connector pattern. In this example, options such as duration (block  802 ), source/destination IP addresses (blocks  804 ,  812 ), time (block  806 ), amount of data (blocks  808 ,  810 ), and protocol (block  814 ) are used to determine when to switch from one modulation package to another. While the variety of factors in  FIG. 8  is demonstrative, it should not be interpreted on a limitation on the scope of the present disclosure. That is, these options are a sample of a larger set of characteristics that may be used to create a connector pattern. In this example, the modulation packages are referred to in a generic sense (e.g., Package A, B, C . . . ). However,  FIG. 9  shows another connector pattern in which a determination (block  902 ) separates packets by protocol, after which different modulation packages are applied to these packets. The modulation packages may be built based on protocol, with some communications control components added. The concept of communications control will be explained further below. 
     Connector patterns can be generated manually, for example by using prebuilt software and/or business rules, or through a larger system output such as machine learning. In the latter case, a big data analytical system may be setup to model data and predict possibilities such as network saturation, vulnerability times, and usability windows. A usability window, as one possible example, may be defined as a time during the workday when administrators need direct access to a backend data store through their client side tools. A learning system receives packets from the target backend data store over time to determine this window dynamically and to alert users when an outlier access attempt is created. In this hypothetical example, such tools may require certain ports to be opened for a small range of protocols. Outside of that usability window, the ports can be closed. Additional data inputs such as past successful intrusions, user behavior, and network load can be input to enhance the predictive model until a point where the model is capable of generating connector patterns that leverage the strength of a given network and reduce an increasing level of exploitable weaknesses. This latter feature again enforces the strength of a distributed deep packet inspection firewall approach. 
     A modulation chart can therefore contain a range of specific modulation packages and an optional connector pattern. This information is optionally stored and transmitted to devices  202  throughout a given network  214 . This information can be conveyed to devices  202  as a text or binary configuration/policy file, a library, an embeddable module such as a COM+ component, a loosely coupled precompiled component such as a DLL, as a new client application or other similar option. In some embodiments, the conceptual steps outlined in  FIG. 8  are reduced to XML-like first level instructions  1002  as shown in  FIG. 10 . It should be appreciated that the instructions  1002  (and  1004  discussed below) demonstrated in  FIG. 10  are conceptual and such a concept may be implemented in myriad ways. These instructions generally reduce the conceptual design into interpretable instructions based on localized resources. In these embodiments, the virtual communications kernel  210  translates semantic items such as Time, DestIP and location into local methods/subroutines and/or programs and passes in the rest of the instructions in turn. The local virtual communications kernel  210  also has access to modulation packages A through G. 
     Further embodiments may utilize an interpreted modulation language to further reduce semantic level instructions  1002  into more actionable interpreted modulation language instructions  1004 . For example, as shown in  FIG. 10 , the semantic level instruction  1002  is broken down into a packet characteristic, or characteristics depending on the filtering complexity/embodiment, a match type, the encryption approach to apply, and the location of any input values required. For sake of explanation, the filtering criteria, match type, approach, and seed values in this example are all singular. It should be noted that each of these can be optionally expanded to contain more options as needed. For example, the first capture line in this example instructs the virtual communications kernel  210  to match on any packet where the IP level CRC value is even. This filter could be expanded to include such options as protocol, sending application, and/or destination IP address. Match values can be statically included as provided in the first capture line or the match can include a dynamic value as provided in the last capture line, which conceptually states that the TCP CRC value modulus the value found at the location identified by the pointer &amp;PointerQ needs to equal 0. 
     The next part of the capture line determines the encryption approach to be applied to the captured packet. The actual approaches may be hard-coded into software, part of an initialization configuration file, or be pulled dynamically through a static pointer. More than one approach may be applied, which could be applied in the order included—for example, right to left or left to right. Finally an optional series of either statically-included values, pointers to dynamic values, or a characteristic of the packet can be included for the algorithms as needed. Note that the last capture line can result in the application of multiple operations to the same packet. In this case, the IP CRC match occurs first and the TCP CRC match occurs second for outgoing packets, whereas the opposite is true for incoming packets, along with the reverse application of an encryption approach (e.g. decryption rather than encryption) applied for matched packets. In cases where values such as CRC or packet size are utilized, the original CRC, TTL, packet size, or other alterable values, may be included in an optional virtualization header  122  to enable subsequent decryption. 
     The interpreted modulation language instructions may be partially compiled in a central location and then transmitted to a device  202 , depending on the embodiment, or completely compiled prior to any transmission. Optionally, the instructions may be Blockchain-encrypted prior to any transmission, as described in detail below in reference to  FIGS. 45-47 . In the case of partial compilation transmission, the ability to complete the full translation may rely in part on code embedded in the virtual communications kernel  210  on the device  202 , physical characteristics of the device  202 , and/or decryption of subsequently transmitted data. In one embodiment, a partially completed modulation chart is encrypted in one manner using a specific user device public key, signed with a central/network private key, and then transmitted to that device  202 . In this instance, a separate set of data sufficient to complete the modulation chart may be encrypted using a standard algorithm along with the current IP address of the device  202  and sent to that device  202 . The device  202  may then use the network public key to verify the authenticity of the incoming data and then use its IP address and private key to decrypt the data prior to finishing the compilation of the modulation chart. 
     By using modulation charts that are sent separately to all devices  202  ahead of time, devices can engage in long-running communications that modulate encryption over time. These modulations provide enhanced security relative to a static, non-changing encryption system. To better understand the implementation of modulation charts in virtual communications kernel  210 ,  FIG. 11  shows an embodiment of virtual communications kernel  210  in further detail. The virtual communications kernel  210  includes a configuration manager  1102 , an operation manager  1104 , and a packet manager  1106 . These managers represent logical constructs and thus may or may not be implemented discretely. Some embodiments may combine all or some of these constructs together, whereas others might re-organize the functional areas. All such embodiments are within the scope of the present disclosure, and these managers are delimited as such for explanatory purposes. 
     The packet manager  1106  is generally responsible for capturing packets of data as those packets leave the last layer within the operating system known space  206  on their way the physical layer  212 . The operation manager  1104  is responsible for applying a given encryption approach onto a given captured packet according to one of the various embodiments described in this disclosure. The configuration manager  1102  is responsible for setting up any variable data such as encryption keys, modulation charts, and so forth. These subsystems can be organized in a variety of ways including in kernel mode only, in user mode only, or across user and kernel modes. 
     Kernel mode is generally defined as a part of an upper level layers  204  where enhanced access to a kernel is provided. Some operating systems  204  do not provide a strict partition, but rather utilize another method for restricting access such as security, authorized access, or even special types of internal protocols. Thus, the concept of kernel mode is used to describe the concept of enhanced kernel access as opposed to restricted kernel access. The region, logical or not, of the upper level layers  204  where access to the kernel is restricted is generally referred to as user mode. Again, different operating systems  204  delineate parts of their system in different ways. User mode may be used to describe a logical or physical part of an upper level layers  204  where access to the kernel is more controlled and/or restricted relative to another region of the upper level layers  204  (i.e., the kernel mode). 
     In general, processes running in kernel mode have less access to other resources such as memory, I/O, and so forth compared to processes running in user mode. User mode processes tend to interact with the kernel at a slower pace and often have a lower processor priority, which may result in slower processing times. In some embodiments, the entire virtual communications kernel  210  may reside in kernel mode to optimize speed. One such embodiment is shown in  FIG. 12 . Here, the virtual communications kernel  210  resides completely in kernel mode  1204 . The packet manager  1106  intercepts outbound data packets and passes those packets to the operation manager  1104 , which performs an operation as described above based on values defined by the configuration manager  1102 . Once the operation or operations are complete, the operation manager  1104  passes the packets back to the packet manager  1106 , which optionally places the packets on the same communication line for transport to the physical layer  212 . One of the limitations imposed by many operating systems  204  on processes residing in kernel mode  1204  is limited access to resources such as memory, which often forces configuration information to be defined during process initiation. As a result, embodiments in which the virtual communications kernel  210  resides completely in kernel mode  1204  may collapse the configuration manager  1102  into the operation manager  1104  and not allow for continuously updated configuration information. Upon launch of the virtual communications kernel  210 , in other embodiments, options such as the applied encryption algorithm, dynamic values such as SALT, and any required key-value pairs are read and may be, for example, contained in locations accessible through static pointers. One enhancement to this base example comprises a two-driver system in which one driver is responsible for executing the packet manager  1106  and the other driver is responsible for executing both the operation  1104  and configuration  1102  managers. 
       FIG. 13  demonstrates an embodiment that leverages a more robust set of resources available in user mode  1202 . In  FIG. 13 , both the operation  1104  and configuration  1102  managers reside in the user mode  1202 , leaving only the packet manager  1106  in kernel mode  1204 . The packet manager  1106  typically remains in kernel mode  1204  due to restrictions on packet access at the level required for implementation of the above-described functionality of the virtual communications kernel  210 . However, in alternate embodiments where the virtual communications kernel  210  is implemented as a separate process outside of the upper level layers  204 , such restrictions are not applicable. In those cases, the virtual communications kernel  210  may maintain the various described manager constructs, but no restrictions exist due to the functional distinctions between user mode  1202  and kernel mode  1204 . Further, in such cases, resources are defined during a process such as the BIOS pre-boot process and are typically based on overall device  202  resource limitations. 
     Referring to the specific embodiment of  FIG. 13 , the operation manager  1104  retains a significantly larger amount of resources, including the ability to retain stateful information about virtualized packets  120  when compared to kernel mode-only embodiments. It should be noted that kernel mode-only embodiments may also maintain stateful information, as some operating systems  204  do provide sufficient resources. However, it is a challenge in many operating systems  204 , particularly those on mobile platforms, to obtain sufficient access to memory in kernel mode  1204 . Thus, embodiments placing the operation manager  1104  in user mode  1202  are able to store virtualized packets  120  for a variable duration. As one example, a given embodiment may store a sent virtualized packet  120  for a duration equal to the time to live value found in the header of that packet  120 . By storing these packets, the operation manager  1104  can respond to retransmission requests from a remote device  202  without having to first send a request back to the upper level layers  204 . This is particularly useful in cases where dropped packets are common, for example in mobile or microwave communications. 
     The operation manager  1104  can also store dynamically generated values such as encryption keys, computed seed values, and similar data for optimized encryption processing by the virtual communications kernel  210 . Although an encryption key could be computed for each packet, it is more efficient to compute a key once and then reuse that key for the duration of the encryption approach. Similarly, a seed value may be a static value or it may be computed by an algorithm such as a time series, location-based, or other such approach. Even in the case of a time series algorithm, storing a computed key or seed value for milliseconds can result in performance improvements through enhanced efficiency. Longer lasting values may also be stored, such as the location of various encryption libraries, session keys to support different communication efforts, time sync values between two devices  202 , and so forth. Running the operation manager  1104  in user mode enables a manner in which to store this information. 
     By locating the configuration manager  1102  in user mode  1202 , configuration information can be dynamically updated in a much wider range of ways. For example, some embodiments may utilize configuration files, whereas other embodiments read remote locations, obtain push updates, or use some combination thereof. As one example, a configuration manager  1102  makes a remote service call to retrieve all or part of the configuration information that it needs, including such items as modulation charts, key generating algorithms, seed values, and other dynamic information. This data is sent to the configuration manager  1102  as part of an authentication process, or an administrative channel may push updates through according to a range of criteria from time intervals to attack responses. In all of these cases, placing the configuration manager  1102  in user mode enables a wider range of possibilities and interactions, including interactions with a logged in user, when compared to running the configuration manager  1102  in kernel mode  1204   
     In many operating systems  204  the movement of a packet of data from kernel mode  1204  to user mode  1202  results the generation of a copy of the packet. Many operating systems  204  retain the original copy while the copied packet is in user mode  1202 . Thus, moving a packet between kernel mode  1204  and user mode  1202  can result in numerous copies of the packet being maintained for some amount of time. Heavy system loads exacerbate the impact of such issues that result from internally cloning the packet. Depending on the embodiment, the device  202  resources, and system allowances, these performance impacts may not be tolerable. 
     For higher-demand embodiments, or in the cases of more restricted devices  202 , such as mobile device, the operation  1104  and packet  1106  managers are placed in kernel mode  1204  while the configuration manager  1102  is in user mode  1202  as shown in  FIGS. 14 and 15 . These embodiments have the benefit of improved speed of kernel mode  1204  processing without the configuration limitations of the solely kernel mode  1204  implementation. In order to access configuration information, the packet manager  1106  could utilize a static pointer  1506 , a mapped memory file, or utilize a protocol such as named pipes to obtain data stored in user mode  1202  amongst other similar options. 
       FIG. 15  demonstrates one such embodiment, in which the operation manager  1104  and the configuration manager  1102  access shared locations in stack  1502  and/or heap  1504  memory. Each manager  1102 ,  1104  accesses these locations using a pointer  1506 , which will be a static pointer for the operation manager  1104 , but may or may not be static for the configuration manager  1102 . In some embodiments, the operation manager  1104  establishes static pointer locations in the heap  1504  and/or stack  1502  that the configuration manager  1102  scans and finds upon either its initiation or during processing. Leveraging shared memory locations allows the configuration manager  1102  to utilize a range of simple values or complex objects, while permitting those objects to be statically read by the operation manager  1104 . Thus, as one example, interpreted modulation language instructions can be further reduced to a series of if-then loop instructions that are written to a shared location in memory  1502 ,  1504  by the configuration manager  1102  based on a new modulation chart. The operation manager  1104  can then compare an incoming communications packet  302  to the current filtering statements and match statically on an updated series of statements. This technique enables fluctuations over time in encryption approaches even while maintaining static kernel mode  1204  processing. 
     As described previously, an encryption approach is a process or method where a given type of encryption is applied to a packet.  FIG. 10  provided one conceptualization of how an approach might be implemented. It is important to note that these instructions can include an algorithm and, as described, moving algorithms to different positions can alter the overall application of approaches or operations even when the modulation sequences are hard coded in a given embodiment. Approaches using encryption are not restricted to just performing encryption and can include other operations in conjunction with encryption such as packet pointer security, communication wrapping, and so forth. 
     The above approach is algorithm-agnostic, since various encryption algorithms may be easily interchanged, and thus gives rise to an open encryption platform concept where any encryption algorithm can be used without requiring higher-level direct knowledge of that algorithm. To accomplish this, various embodiments of the present disclosure support a common interface across algorithms. This interface is one to which all algorithms are written, which is the case for example with class factory adaptations. Alternatively, the open encryption platform could be encapsulated in a common wrapper that still supports a class factory approach, but more similar to a distributed library technique such as those found in dynamic link libraries. In all such cases, the use of static pointers, large object constructs such as arrays, and other such input options provides a layer of abstraction at the interface level. Other embodiments might utilize encryption-on-a-chip wherein a chip manufacturer provides a standard interface and the actual algorithm is not disclosed. Subsets of these embodiments might switch out the encryption on the chips, accordingly to the same range of possible rules described previously, thus changing encryption without modifying the interface with the chip itself. These latter embodiments give rise to out-of-band encryption management where such features as encryption algorithms, keys and SALT can be modified independent of the parts of the virtual communications kernel  210  that are actively processing packets. 
     As one example,  FIG. 16  shows a given embodiment that utilizes a static memory pointer to obtain an array of instructions for the algorithms to be used.  FIG. 16  is provided for sake of explanation, but should not be interpreted as providing a limitation on the scope of the open encryption platform disclosed herein. In  FIG. 16 , the operation manager  1104  reads an encryption pointer array  1600  to obtain a list of available encryption options. In this case, each option has a pipe-delimited list of other pointers that point to a target encryption algorithm object location as well as to a text array to be passed into each encryption object. This simplified interface therefore takes in one generic text array with a variable number of entries. In the case of the first encryption option, Encryption A, the algorithm object is an AES 256 Bit Algorithm into which the text array found at the location designated by the pointer &amp;PointerF  1604  is used. Within the text array retrieved from that location, for the purposes of this example, square brackets denote dynamic data that the operation manager  1104  needs to replace prior to passing that information into the algorithm found at the location designated by the pointer &amp;PointerQ. In this case, the dynamic values are media access control (MAC) address of the device  202  as well as the destination TP address and TPC-level CRC of the individual packet 
     Certain embodiments may load the encryption pointer array  1600  at startup, while others load might load the array  1600  on demand, while still others might load the array  1600  on startup and then periodically check that array  1600  for updates. Similarly, the referenced algorithms can be loaded and/or updated at different times in various embodiments. In dynamic-loading embodiments, dual processes can be instantiated with the encryption options to be changed maintained in one instance and the new values in a second instance. In these cases, new packets are transferred to the new instance while the old instance is maintained for a specific period of time to manage packets that utilized the old values. A possible time period may be defined as the maximum TTL for any given packet. These techniques allow for an algorithm-agnostic approach that enables a dynamic open encryption platform. The open encryption platform can be thought of as supporting “pluggable encryption.” That is, as long as a given encryption option meets the interface requirements for a given embodiment, that encryption option can be added to the platform at any time without requiring major revisions to the overall virtual communications kernel  210   
     To protect against exploits such as cold boot or RAM or similar, attacks, certain embodiments of the present disclosure might require all encryption options to be signed using a known certificate or key. Other embodiments might, instead, require that the encryption objects or code be sent in an encrypted format to the device  202  and then decrypted and instantiated/compiled at runtime on the device  202 . In these latter cases, the encryption may utilize a device  202  public key that can only be decrypted on the local device  202 . This key may be a general key for the device  202  or the key might be a key generated just to transfer one or more encryption options to the device  202  such as in a blockchain environment. In a similar manner, other embodiments may require all data referenced through a pointer to be encrypted prior to being stored in memory. In these cases, the configuration manager  1102  can be used to carry out these encryption requirements. The encryption utilized might be one of the options made available to the operation manager  1104 , with optional different input values, or a distinct encryption option might be used for either or both the encryption options and the other stack  1502  values or heap  1504  objects. 
     As noted above, another important aspect of a comprehensive communications security solution is the ability to control communications between devices. Unlike prior efforts such as IPsec, which only encrypt data between devices, the present disclosure also extends into authenticating and authorizing communications between devices  202  before any communications can even occur. 
     A central concept to the disclosed communications control embodiments is that of an active user device, which is at times also referred to as a user device. Turning to  FIG. 17 , a device  202  can have a variable number of users  1702  with access to that device  202  at any given time. In fact, especially in the case of backend services and processes, there can be a variable number of active users  1702  on a single device  202  at any period of time. However, for a specific communication stream, there can only ever be one active user  1704  on a given device  202 . This single active user  1704  for a specific device  202  communication stream is referred to as an active user device  1706 . A device  202  in this case can be a physical device  1804  or a virtual device  1800  as shown in  FIG. 18 . This gives rise to virtual active user devices  1802  and physical active user devices  1810  which may or may not interact, on even be nested as is the case for physical devices  1804  hosting one or more virtual devices  1800  or parts therein, depending on the embodiment. 
     As will be discussed, utilizing a variable first-class membership authentication system enables handling these virtual active user devices  1808  in a novel manner By elevating users and devices to the same first class member status, rules can be applied to virtual and non-virtual users  1702  and devices  202  and combinations therein by applying a different set of rules to different combinations. Thus a virtual machine, which is typically an application running on a device  202 , can be assigned a range of authorization rules. As one example, a general rule might be conceptually “no Internet access”. Thus a virtual administrator running in the virtual machine—with complete access to that machine—would not be able to access the Internet due to the general communications control list  2600 . Another, more interesting, rule might be a downgrade rule for an example such as classified documents. Within this example, a given device  202  might state that all users are restricted to a maximum of security clearance based on device location, network access and other such options. Thus a person with top secret clearance, using a desktop device with unrestricted access, utilizes a VPN to bypass a local network and can only obtain normal secret documents. By elevating applications to the same first-class level, these communication control rules can be extended even further. In these embodiments, applications such as an Internet browser might be preventing from writing to an operating system for certain users  1702  on particular devices  202 . 
     As yet another example, assume the virtual active user device  1808  is granted super user access on a virtual device  1800  and the physical active user device  1810  is granted basic user access on the physical device  1804 . For purposes of communication, there might exist a general communications control list  2600  preventing any off device access for virtual devices, which precludes the need to combine active user device definitions together, or there might be a policy that treats virtual users the same as physical users. Other embodiments might simply assume the physical active user device  1810  rights for all processes hosted within, which again precludes the need for combining rights. Other embodiments may combine rights where the resultant active user device is a logical combination that creates a virtual physical active user device  1808  and  1810 . All of these options are possible, both across different embodiments and within a given embodiment, as different types of active user devices  1808 ,  1810  might require different approaches. To this latter point, working in a sandbox or isolated environment may permit more lax rules whereas working in a sensitive production area or highly-connected public environment might require a more stringent set of communication rules. 
     Combining the communication control list with the virtual communications kernel  210 , enables unique protective features. In certain embodiments, as one example, virtual communications packets  302  can be tagged by the virtual communications kernel  210  to do denote a user access level and an origin. On the way into another physical device  1804 , the virtual communications kernel  210  can read its active users&#39; communication control list to determine where and how to route incoming communications packets  302 . In some embodiments, a virtual communications packet  302  might have a single tag denoting that it was sent from a virtual device  1800  through a physical device  1804 . The receiving physical device  1800  might remove the tag and the virtual device  1800  might reject any communications packets  302  with the tag present. In these embodiments, processor flaws enabling malicious attacks within a physical device  1804  across hosted virtual devices  1800  would be blocked due to the tagging of the communications packets  302 . Other embodiments can leverage the virtual communications kernel  210  to reject any incoming communications packets  302  that do not have the correct tagging thus enforcing communications control lists  2600  for active user devices at the level of each incoming communications packet  302 . 
     Turning to  FIG. 19 , there are typically two participants within a given device  202  for a specific communication—an active user  1704  and an application  208 . The present disclosure also relates to the concept of an active user device application  1900 , which further extends communications control to the application level. As has been discussed, this provides for a deeper level of control. However, for the sake of clarity the following largely focuses on the active user device level. 
     Most modern LDAP systems utilize a single first class member and then assign characteristics, otherwise referred to at times as metadata, attributes, tags, or some other similar term, to that first class member. For example, many modern LDAP systems provide users as a first class member and then assign a tag such as group membership to each user. Resource access rights are typically assigned to the tags, which provide a group-based security system. Other LDAP systems use devices as the first class member. The use of a single first class member creates security weaknesses, which are addressed by embodiments of the present disclosure. 
     As one example, assume an executive who accesses sensitive corporate documents from both a central, secure office building and also remotely from that executive&#39;s mobile device. When the executive accesses information from the central office, that active user device should likely have a different set of access rights than the active user device that stems from the executive&#39;s access from a remote location. Further, it may be desired to provide the executive with one set of rights when accessing the corporate network from a “friendly” location (e.g., where cyber-attacks are less likely) as opposed to an “unfriendly” location (e.g., where cyber-attacks are more likely) in the world. That is, geographic constraints may also influence the permissions afforded to a particular active user device. However, by only utilizing a single first class member, the authentication capabilities in modern LDAP systems are unable to assign such differential rights based on the interaction of a user and device much less by location. 
     In accordance with various embodiments, the implementation of active user devices  1706  provides an improved two-member authentication system where both users and devices are elevated to first class members. This approach enables a new type of interaction, the active user device  1706  rights, which can be directly utilized or managed through indirect interactions. Rights can be assigned to devices based on device group membership and users based on user group membership and then rules can be created to control combinations of those memberships. As one example, a rule for executives might be that only executives can read any document on the corporate secrets server. In this example, mobile devices might have a rule stating that they can only read documents up to general secret protection. Thus an executive on a mobile device might get a resultant rule stating that they can read any document on the private secrets server that has been marked as general secret or lower. These rules are generally provided in a communications control list  2600  which is similar to an access control list but focused on communications control instead of resource access control. Rules for collisions, similar to the rules used for group membership collisions in modern LDAP systems, can also be used to control user and device interactions. Examples of such rules are user wins, device wins, hierarchical determination, and so forth. Other interaction management options will be apparent from the disclosure herein. 
     By providing an active user device  1706  paradigm, options such as device location can be included as additional attributes either directly to the active user device  1706  construct, to a user, or to a device. This enables further refinement within the active user device to provide a differential set of access rights depending on dynamic information such as, for example, geographic location. All of these concepts, while discussed with respect to resource access up to this point, can be similarly applied directly to communications. 
     This concept of location-based authorization for active user devices  1706  can be further extended in some embodiments to include the concept of geographic intelligence. In this manner, a type of device might be provided with a set of restrictions based on changes in location. As one example, a desktop computer might not be allowed to travel more than 100 miles in an hour but a mobile device might not have this restriction. These restrictions introduce another communications access rights paradigm discussed more fully in the next section. In response to violating a location-based rule, a device  202  might be forced to re-authenticate, the virtual communications kernel  210  might be uninstalled or the entire user device  1706  communication capabilities blocked or redirected until a properly authenticated user unlocks the user device  202 . This latter communications control might be contained within the one offending user device  1706  or, depending on the embodiment, all user devices  1706  for that device  202  or that user  1702  can be affected. Movement is not the only type of location-based rule as, for another example, there might be rules based on multiple logins by the same user  1702  or device  202  from different locations. These latter rules might range from not allowing multiple locations to allowing multiple locations within some defined distance variable on device type and so forth. 
     Communications access rights also provide the ability to restrict initial communications in a variety of ways. At the device level, types of devices (e.g., desktop, laptop, mobile, manufacturer, or operating system) can be directly managed. As one example, all mobile devices might be required to only use certain ports or be restricted from certain subnets within a network. Users might also be directly managed in terms of communication, for example all accounting personnel cannot initiate communications with TT personnel, or only an executive can initiate communications with an employee. Rights can also be applied on the receiving end; for example, billing personnel cannot accept any communications outside of a given protocol. Communications can be restricted or locked down by any characteristic of a communications effort including such options as network used, protocol, application, data type, time of day, duration, and amount of data. These options provide support for complex communications control options that may extend far beyond what is available in the prior art. As another example, consider a background service that obtains updates from a central server every day at 1 AM. As shown conceptually in  FIG. 26 , a communications control list  2600  entry for that service might only allow that service to provide any off device communications at 1 AM, only allow one request to be sent out, and only allow one response in, up to a finite amount of data over a specific protocol from a finite number of allowable active user devices. “Off device communications” can refer to data sent outside the physical boundaries of a device as opposed to internal device communications, which are typically communications within device boundaries, such as applications communicating across application domains or a given application requesting, for example, I/O access. 
     Some embodiments include communication characteristics such as protocol, network type, throughput, network hops and so forth, as additional attributes added to users and/or devices, where other embodiments create yet another first class member. This latter feature reveals the potential of a variable first class membership authentication scheme. In this latter set of embodiments, the communication control features are appended directly onto groups of communication types and those types may be defined by any characteristic of a communication effort. Thus given groups may be defined communication control characteristics, further including options such as port numbers, geographic locations, internal vs. external, subnets and so forth. Control can then be applied by other options such as type of data, amount of data, duration and time of day amongst other features. This first class member can then be combined with users and devices to enable a rich series of interactions that fully lock down communication access to whatever degree is required by a given network or enterprise. As one example, a first class insecure communication member might have a general restriction of not allowing any level of secret data. This first class member might be defined by broadband networking protocols. In this case, an executive authorized to access regular secret and general information on a laptop would lose access to secret information when the laptop transitions from a local wireless home network to the broadband connection from the café next door. 
     Returning to the use of applications as a first class member, there are a number of reasons for extending control down to this level. First, an administrator can group applications together using any semantic category, which are used throughout modern LDAP and would be an option for any first class member in that respect. As one example of semantic categorization, an administrator might create application groups such as personal, background, employee work, employee social and so forth. Administrators, and/or any appropriately authorized user, can generate a semantic definition as required and even overlap definitions for different enforcement reasons. Traditional definitions by business unit or corporate hierarchy might be used as well as trusted vs. untrusted people, number of years of employment, certifications obtained, behavioral testing results, and so forth. Each of these application groups can then be controlled in any manner desired in order to not only control the communication lines and protocols allowed by an application, but also with which other applications a given application can communicate or other application resources a given application can access. For example, a web browser might be designated in a high risk group with no access to employee resources on a computer or that group might not be allowed to save information if the total amount to be saved exceeds a certain size. Both of these restrictions aid in countering potential malware attacks from being downloaded and/or accessing data. 
     As will be discussed in more detail, prior authorization schemes rely on the first-class member authentication in order to determine authorization rules. These rules or configuration settings are most commonly referred to as Access Control Lists or ACLs. Since these systems only support one first class member, they are unable to provide interactions required for more detailed authorization requirements. As one possible example, a given file system might preferentially enable access to parts of its file system based on a user&#39;s security clearance. While an administrator might want to further define restrictions based on the device being used, in the current authorization implementations, this is not a possibility. In the variable first class membership authorization system described herein, the interaction of a distinct device first class member resolves this issue. Extending the current example, an administrator might enable full access to desktop devices but only allow non-secret access to mobile devices. Thus a person with top secret access would end up having differential access to a file system based on device type. 
     Taking this concept one step further, another first class member option can be communications, which can include both internal and external communications. One of the basic ways that malware spreads is through the use of scripting commands, such as PS Install, to automate the spread from one device to another. These commands are relied upon by allowed applications and operating systems and, as such, are not easily removed from a network. Further, many malware attacks will utilize these types of commands across a range of possible ports, sometimes referred to as port scanning, in order to determine an open port on a target device  202 . In these cases, the communications control list  2600  can be leveraged along with the user device application construct to prevent these types of attacks. In the first instance, certain embodiments can prevent an application from transmitting packets unless the correct active user  1702  and device  202  are included in the communications. Therefore, applications attempting to transmit a command such as PS Install can be blocked at it source. In the latter case, a receiving device  202  can identify a port scan and block all communications from a suspect device until a signal from the correct active user device application is received. 
     Various embodiments of the present disclosure also provide the ability to monitor through existing techniques such as DTrace in order to maintain other rulesets. In this regard, one of the main challenges facing prior security is a weakness known as active scripting. Active scripting allows small programs to run within the context of a web browser in order to support more advanced user interactions. However, these nested applications often require resource access outside of domain of a standard application. Since there are no communications control options in prior LDAP systems, there is no way to lock down active scripting sessions, creating a vulnerability that is a source of attacks. For purposes of the present disclosure, communications also include data flowing within a device between application boundaries. One such boundary is that between a given application, such as a web browser, to device options such as a processor, file system, or memory. 
     This control enables the lockdown of a web browser, for example, such that it is only able to download a finite amount of data in a controlled space. On the external communications side, that web browser can be locked down such that the external IP address locations available to be accessed are controlled and can be optionally further refined by protocol. Thus, a given web browser might be allowed to use the FTP protocol for a finite set of IP addresses representing internal FTP servers, only the HTTP protocol for all other IP addresses, and no communications for IP addresses representing a given country. Any binary responses coming into the web browser can be locked down, for example using an option such as DTrace or the above-disclosed virtual communications kernel  210 , such that the total amount of data allowed is fixed to be below a predetermined threshold. Utilizing the active user device application construct, these rules can be differentially applied such that a security admin might have more open access than an intern. 
     In order to support a variable set of first class members, in accordance with various embodiments of the present disclosure, a new type of authentication system is provided. Whereas some applications already provide identification techniques, the process of authenticating users  1702  and devices  202  is more difficult. In fact, many of the challenges facing modern communication security relate to how to establish secure communications. The restriction in these cases is that two devices  202 , having not previously communicated, cannot exchange secure communications until a secret is shared between them. This secret is used for encryption, which is how current encryption operates, and the secret needs to be received by both devices  202 .  FIG. 20 a    shows one approach, public key exchange (PKI), which attempts to resolve this issue. These approaches are generally considered to be inline session initiation protocols since the session initiation occurs in the same path as subsequent communications will occur through. However, inline initiation approaches have been a point of weakness and source of exploitation for a number of years. 
     In accordance with various embodiments,  FIG. 20 b    shows a system for out-of-band session initiation, which is an alternative to the inline initiation of  FIG. 20 a   . The scope of the present disclosure should not be construed to be restricted to any particular architecture; rather, options such as client/server, peer-to-peer, mainframe, hybrid peer, and so forth are understood to be within the scope of this disclosure. While further disclosure may revolve around more traditional architectures, this is provided for the sake of clarity and brevity. For example, referring briefly to  FIG. 23 , the authenticating client  2300  could be a peer node within a peer-to-peer context that has access to an authentication client  2302 . This access might be a static construct such as is found in traditional RADIUS/DIAMETER systems or it might be a dynamic construct based on a distributed mobile architecture and based on the active user device  1706  instead of static device placement. In this regard, the ability to authenticate both the device  202  and user  1702 , as will be explained, that removes many of the issues facing traditional authentication systems and the relative inability to secure remote connections without significant delays. 
     A given active user device  1706  can, as one example, include a separately authenticated active user device application  1900  that can act as an authentication client  2300 . Depending on the embodiment, the authentication client  2300  might be comprised of more than one device  202  as will be described in a subsequent section. 
     Referring back to  FIG. 20 b   , out-of-band initiation requires authentication of two would-be endpoints  202   a  and  202   b  of a communications stream with an authenticating peer  2000 . This authentication process can then be leveraged to send each authenticated user device  1706  a secret enabling secure communications. This out-of-band approach provides an enhancement over the prior art in that no unprotected data ever travels over the same lines that need to be protected (i.e., for subsequent communication between the user devices  1706 ), but unprotected authentication  2010  itself can still be utilized. In fact by utilizing the previously described modulation charts, even first time requests can be protected between two user devices  1706  that have never communicated with each other before. The receiving user device  1706   b , in these cases, would be able to use a modulation chart, an embedded static encryption approach, or some other previously presented option, to attempt to decrypt a first-time session initiation request. This concept is discussed in further detail below with respect to proactive network defenses. 
       FIG. 21  shows the exchange of information in an authentication system in accordance with various embodiments. In  FIG. 21 , a device  202   a  sends an initial request  2002  to an authenticating peer  2000 . The authenticating peer  2000  provides a protected response  2102  using an option such as SSL or TLS or, in embodiments using modulation charts as previously presented, the virtual communications kernel  210  might provide this protection. This response  2102  is labeled as protected since SSL/TLS both use inline session initiation and the protection would be considered secure if the virtual communications kernel  210  was involved in the communication. Once the protected response  2102  has been established, the authentication peer  2000  transmits a virtualization client  2100  to the device  202   a . This client  2100  may take the form of any type of code that can be run on the device  202   a . This includes such options as a precompiled application, an installer that either includes all of its code or pulls data from a remote location, or a script/program that can run in a web browser. The purpose of this virtualization client  2100  is to either install the disclosed virtual communications kernel  210  on the device  202   a  or provide the intermediary user and device information sufficient to complete authentication. The presence of the virtual communications kernel  210  does not define a user device  1706  nor is its functionality required to define a user device  1706 . Likewise a virtual communications kernel  210  can run on any device  202  and does not require a user device  1706  on which to function. 
     A virtual communications kernel  210  can operate in a functional manner without any authentication or authorization and does not require such systems and processes as described herein. As one example, the virtual communications kernel  210  can run on devices  202  and encrypt all or a portion of the communications between those devices without any authentication. In this example, the authentication and authorization might take place in a standard LDAP system or through application-level processing. At the same time, the described authentication, authorization and accounting enhancements described herein need not incorporate a virtual communications kernel  210 . While certain advantages may be realized by combining the disclosed virtual communications kernel with authentication and authorization processes, triple A Services may be supported by a range of options including applications  208  running in the upper level layers  204 . 
     To this end, the present disclosure provides embodiments where the virtual communications kernel  210  is installed on the device  202   a  prior to authentication. These embodiments are exemplary and should not be considered as required. None of the functionality required for the disclosed authentication scheme requires the virtual communications kernel  210 —although the virtual communications kernel may enhance speed by operating logically below the operating system and provides further security opportunities described in further detail below. That stated, some embodiments will not install the virtual communications kernel  210  until at least the device  202  or user  1702  have been authenticated and other embodiments will require full active user device  1706  authentication prior to installing the virtual communications kernel  210 . 
     Further, the disclosure focuses on a single active user device  1706  authentication process and does not include cases where prior users  1702  have been authenticated on a device  202 , nor does the disclosure distinguish between an end user authentication effort and a backend process or service authentication. In cases where the virtual communications kernel  210  already exists due to separate active user device  1706  authorization, the actual installation component might be an activation sequence for the current active user device  1706 . Other embodiments might uninstall the virtual communications kernel  210  if authentication fails, or even each time a new authentication initiates (for end users only or varied by type of user  1702 ) for any user  1702  on a given device  202  and/or lock the current user  1702  out of the device/disable said service or process. Some active user device  1706  authentication processes will only enable one end user authentication per device  202  at any given time and handle pre-existing by preventing the current authentication or ending authentication for any current end user devices. Other embodiments might set a total number of active end user devices whereas others will either extend this limit to all active user devices  1706  or vary limits by active user device  1706  type. In these cases, deactivations might occur in a range of manners such as priority numbers, first in/last out/first in/first out, and so forth. 
     In some embodiments, the virtual communications kernel  210  includes information sufficient to establish secure communications and subsequent authentication can proceed. In other embodiments, however, the device  202   a  first needs to be authenticated itself If the device  202   a  is to be authenticated, the virtual communications kernel obtains sufficient information from the device  202   a  to uniquely identify the device  202   a . Again the virtual communications kernel  210  is not required at this juncture as these operations can be completed by any sufficiently authorized process such as pre-existing services, downloaded code, application or scripts and so forth. Such information may include the media access control (MAC) address, any or all IP addresses and BIOS/UEFI (unified extensible firmware interface) information. This information  2106  is sufficient to identify the current device  202   a  and, once protected and sent back to the authenticated peer  2000 , the device  202   a  can be authenticated. 
     In order to protect the device data  2016  going back to the authenticating peer  2000 , some embodiments may generate a private/public key pair and then sign the device data  2106  with the private key pair. Sending the signed content and the public key will ensure that the authenticating peer  2000  can ensure the data came from the device  202   a , at times referred to as digital signatures, but it does not protect the data  2106  from being intercepted. Other embodiments might thus utilize a public key sent from the authenticating peer  2000  to the device  202   a  in order to encrypt the device data  2106  prior to transmission. This ensures that only the authenticating client  2000  can decrypt the content. Some embodiments encrypt the signing hash, device public key, and content; others only encrypt the content; and yet others will not use a device public key and only use the authenticating peer  2000  key. Each of these keys can be privately-computed, third party-generated from a certificate authority, or themselves be certificates. 
     Further embodiments may require the ability to add in an additional layer of device  202  authentication by utilizing the exemplary process shown in  FIG. 22 . The main concept is to include as one of the values inputted into a key generation algorithm the values being utilized to uniquely identify a given device  202 . In this manner the public key can be subsequently analyzed in order to verify device  202  authenticity. To understand this process more fully the following explanation of the key generation process is provided. 
       FIG. 22  shows a method  2200  in accordance with various embodiments. The method  2200  begins in block  2201  with receiving the various elements comprising the unique device data. The method  2200  continues in block  2202  where the unique device data elements are hashed using a hashing algorithm such as MD5, which results in a number, e. The method  2200  continues in blocks  2204  and  2206  with selecting co-primes p and q of e, respectively, that are each greater than half of e. The method  2200  then continues in block  2208  with multiplying p and q to obtain the modulus n, which needs to be greater than the original hash e as determined in block  2209 . After ensuring this rule, the method  2200  continues in block  2210  with calculating the totient(n) by subtracting 1 from both prime values p and q, and multiplying those two results together. In block  2211 , the method  2200  includes confirming whether the totient(n) and the original hash e are coprime. If the totient(n) and the original hash e are coprime, the method  2200  continues in block  2212  with calculating a  0  modulus value d for (e*d−1) mod (totient(n))=0, at which point a public and private key can be obtained in block  2214 . The public key is then comprised of modulus n and e, which is the hash of the device data. This optional process therefore embeds that hash directly into the public key, thus ensuring that the public key came from that device. At any point in the future the device can be asked to re-generate the key pair in order to verify this hash. 
     It is noted that this is just one example to demonstrate the concept. Generating keys can also utilize SALT values and, indeed, alternative embodiments utilize this latter option in turn. Generally, a unique manner is provided in which a public private key can be generated with the public key being tied to physical attributes of the device  202   a  in some replicable manner Other options include using the physical attributes of the device as a modifier parameter or even utilizing a closest prime approach, where the two closest primes to the hash value e are used. In this later case, the totient(n) value would always exhibit a correlative relationship with the modulus n, which is commonly included as part of a public key. Further embodiments might also include unique user  1702  identification information, as is commonly found in LDAP systems, to create a key attributable to a user device  1706 . 
     Referring back to  FIG. 21 , the authenticating peer  2000  then obtains the device data  2106  from the device  202   a  which has been optionally signed with a device private key and encrypted using the authenticating peer&#39;s  2000  public key. Additional information such as the device  202   a  public key may also be sent depending on the embodiment. At this point the authenticating server  2000  is able to authenticate the device  202   a  and the device  202   b . In fact, given that the virtualization client  2100  can also be signed to ensure unaltered delivery, this approach closes the security gap in first time authentication efforts. Once the virtual communications kernel  210  is installed, the secure features of virtualized communications described above can be implemented and this, in turn, provides yet another avenue for secure communications as will be discussed further with respect to  FIG. 23 . 
     As will be discussed in a later section, communications can be secured using in-session keys. For the purposes of authentication, a newly activated virtual communications kernel  210  might obtain, or have embedded in it, a temporary session key. As shown in  FIG. 23 , an authenticating peer  2000  may store a variable number of virtualization clients  2100 , each with its own unique session key. These keys might be embedded in the code, in a precompiled manner, included in a signed download as metadata, and sent as part of a longer communication data stream separate from the virtualization client  2100  itself. In some embodiments, these session keys might not be the actual session key but rather a unique identifier, such as a GUID, that is subsequently sent to the authenticating client  2000  in order to obtain a session key. 
     In all of these cases, the session key can then be used to establish virtualized communications upon the first response back from the device  202   a  when it transmits the unique device data  2200  to the authenticating client  2000 . Some embodiments may allow the SSL/TLS connection to continue, while others may drop that connection altogether. Other embodiments further include a modulation chart, in a manner similar to the manner in which the session key is included, to provide additional flexibility. The modulation chart may also be provided in other manners. The modulation charts may wrap protocols and/or send communications out of nonobvious ports in an effort to better obscure communications. As one example, a common vulnerability in IPsec VPN implementations is the use of well-known ports. Since would-be intruders know ahead of time which ports to monitor, and because of current in-line initiation protocols, these intruders are able to sit and listen to certain ports and wait for an opportunity to infiltrate a given VPN connection. By utilizing other ports, a much greater effort is required to capture outgoing traffic. Even in environments where traffic flows over known ports, intruders also typically need to know the expected protocol in order to effect viable decryption operations. In embodiments of the present disclosure, where one protocol, such as HTTP, is nested inside another, such as SMTP, efforts required to obtain the base data become more difficult. This feature is discussed in further detail below. The use of this type of communications security approach does not obviate the encryption approaches provided for securing the device data. In fact, separate and distinct encryption beyond the communications encryption covered in the modulation charts/encryption approaches can be carried out for any data and even those options can be controlled using a modulation chart. 
     Once the virtual communications kernel  210  and the authenticating peer  2000  have exchanged device data  2200 , the device can be authenticated. This authentication can occur through a range of options including complex lookups in logical data repositories, hashing and encryption techniques to reduce lookup complexities and so forth. Within this context, the authentication of a device is reduced to the general authentication processes for any first class member within this authentication system. In general terms, this process consists of utilizing uniquely identifying information of a first class member, either directly or through a remote system interface and the like to look for the presence of that first class member. If the member is found then that member&#39;s information can be retrieved and used in a variety of manners. Depending on the member and embodiments, that information might be used as part of a challenge response back to the user  1702  (challenges can be distinct as well from this information) or the data can be inspected to determine next authentication steps. If the member is not found then various rules based on any characteristic of the member can be implemented. As one example, a new mobile device might be allowed to be assigned to a user generically but needs to be dependent on a next authentication step. Conversely a known exploitation device might be rejected in turn prior to any further authentication efforts taking place. 
     In some embodiments, the deployment of the virtual communications kernel  210  may occur along with protected information from a deployment controller. Some examples include a deployment key pair, a secure hash table or a set of algorithms personalized to each deployment. The key pair could then be used such that the controller maintains the public key, the new device maintains the private key and thus a challenge-response can be uniquely protected between those two devices. A hash table is advantageous when a given device has very restricted resources and cannot maintain complex encryption processes. In these embodiments, a custom hash table is generated based on a range of options from sensor input matching to packet pointer value lookups to any other communication attribute available on the new device  202 . In these embodiments, the unique hash table provides both protection and, since there is only one sending device  202 , authentication of the source of a communication stream. The custom algorithms provide a sophisticated challenge-response paradigm wherein connecter patterns can be utilized to optionally connect input and outputs from synchronous algorithm sets. Therefore even if an initial challenge value is captured, the resultant response would not be able to be calculated outside of the two authenticating devices. 
     After device authentication is complete, the next step is to present to the user  1702  of the device the ability to provide user-level authentication information, which is detailed in  FIGS. 21 and 24 . In traditional RADIUS/DIAMETER terminology, an authenticating client  2300  is an endpoint on a network to which unknown users can make authentication requests. In these paradigms, an authenticating client  2300  queries the authenticating server  2302  and obtains a challenge from the authenticating server  2302 , which is then passed to the device  202   a . While the most common format of such a challenge is a username and password request, there are other options. Some systems rely on MAC addresses, some rely only on a password, where others require username, password and security questions. Some authenticating servers  2302  will utilize a range of challenge responses that may extend past the current device  202   a . For example, many banks may require a second challenge be completed by texting a secret code to a user&#39;s mobile device. During this phase of authentication all of these options can be supported. 
     In order to support communications control, however, standard authentication is often insufficient because of a gap between where and with whom communications are occurring. Devices  202  are actually performing communications that support users  1702  who are typically exchanging data. By ignoring the device  202 , differential communications options are not enable based on location and/or device characteristics. By failing to include users  1702 , a given device can provide open access to all potential users on that device despite a need for isolated and/or varying levels of communications security. 
     While some embodiments require interaction with an authenticating server  2302  that handles communications control, others rely on a separate communications authentication step. This separate, but related, communications authentication step which might be subsumed in the authenticating server  2302  processing and may occur prior to user authentication. As one example, a given network might not allow any mobile devices and, once identified, a given device might be rejected before any user authentication can occur. In a situation where a user  1702  and/or device  202  fails authentication, the downloaded virtual communications kernel may be optionally disabled or automatically uninstall. In some embodiments, if a user device  1706  is active for more than a set amount of time without connecting to an identified network, the virtual communications kernel  210  might disable or uninstall itself. Once an accept response has been obtained from all systems responsible for authentication, the device  202   a  becomes a user device  1706   a  as shown in  FIG. 21 . 
     Referring now to  FIG. 25 , the authenticating client  2300  is an exemplary logical construct that can be implemented as one application on one device  202 , as multiple services on one device, across numerous devices  202  as a variable set of services, and so forth. Additionally, the authenticating client  2300  may include a logical communication control list  2600  store  2506  (e.g., a SQL/NoSQL data store or as in memory cached set of values). An authentication client interface manager  2500  can handle user interactions, maintain state as needed and orchestrate the above-described authentication process as needed. A virtualization client manager  2502  may control the deployment and monitoring of virtualized clients  2100 . The virtualized client manager  2502  may generate new virtualized clients  2100  in cases where the session key in embedded, or manage entries in a data store where sent GUID values result in subsequently transmitted session keys. The virtualized client manager  2502  may also load balance installer requests in cases where user demand overwhelms a single location or client  2300 . A user manager  2506  can control the actual communications control list  2600  if one is sent separately for communications as shown in  FIG. 26 . 
     A communication control list  2600  can either be included as part of a general access control list or stored/managed separately. In those embodiments where the list  2600  is stored separately, it can be sent to the user device  1706  or it can be retained on the authenticating client  2100 . In  FIG. 26 , an example is provided that shows how embodiments might separate initiation from responding based on device, protocols, times, and the like. General restrictions for an entire user device  1706  are not shown, although these may be either be stored locally or sent to the user device  1706 . In cases where the control list  2600  is sent to the user device  1706 , there is a speed advantage and a proactive (i.e. before the operating system is aware of an interaction) ability to stop unwanted communications. For embodiments that maintain these control options on the authenticating client  2300 , a slower response time may result, but an increase in control access list  2600  security is present. In terms of security, in embodiments where the control list  2600  and/or the device control data is sent to the user device  1706 , some embodiments will encrypt the content both in disk and in memory, while others will do one or the other, and yet others will provide no encryption and/or not store the list  2600  on the device. 
     The user manager  2502  also creates new user entries in either the logical communication control list store  2506  or through a security system integration manager  2504 . In embodiments where the communication control list  2600  information is stored separately from the access control list data found in an LDAP system, the user manager  2502  creates entries, as needed, in the logical communications control list store  2506 . The logical communications control list store  2506  may be a data repository existing in memory, on a disk, or some other storage variation. The store  2506  may be comprised of a local version and a remote version for distributed storage purposes. In other embodiments, a separate function or system handles all control list requests and processes create, read, update, and delete access control list  2600  requests based on a series of rules. These same types of rules may be included on a resident authenticating client  2300  and/or the user manager  2506 , in the event that it is implemented as a separate process. Rules may include such things as total number of devices allowed per user, user type, or group. Other rules, applied at various levels, may include such things as type or types of devices allowed, location, operating systems, and even number of active devices per user. 
     Regardless of whether rules are stored in the main LDAP system or separately in the authenticating client  2300 , these rules can be used to determine whether an authenticated device  202  belongs or can belong to a given user  1702 . If a device  202  has already been registered to a different user, then the question of whether a given device  202  can be multi-tenanted can be addressed through attributes applied to either the device or a device group. User devices  1706  may have additional restrictions that enable or disable simultaneous active users  1704  on a given device  202 . Such a rule, as one example, could lock down all communications by other active users on a device when a logged-in executive initiates a multimedia web conference. Thus these rules can be applied both to the authentication process of whether a given device  202  can be applied to a user  1704 , the determination of behavior of the user device  1706 , as well as the effect of that user device  1706  on other active users  1704 . Other embodiments might act even further to isolate a given active user device  1706  for a range of reasons. As one example, a given active user device  1706  might attempt to initiate illicit communications and thus be identified as potentially hosting malware. In response, all other active user devices  1706  on the same network as the target active user device  1706  might either be logged off, prevented from communicating with the target active user device  1706 , forced to use a separate subnet or distinct protocols, some combination of these options and so forth. Given the connected nature of user devices  1706  to authenticating clients  2300 /peers  2000 , the clients and peers might control this response. In other embodiments, a separate system such as an administrative channel might handle these responses or even embedded code, in response to different types of communications, might elicit this response both for the current device  202  as well as all other connected devices  202  or  1706 . 
     The security system integration manager  2504  integrates access control information in embodiments where the access control data is not sent directly from the authenticating server  2302 . Whereas typical access control protocols might base all authorization on responses from the authenticating server  2302  through the authenticating client  2300  to the user device  1706 , communications authorization may not always be included in that path in certain embodiments. In these cases, the security system integration manager  2504  obtains the authentication and/or authorization responses from the authenticating server  2302  and uses that information to look up values for the active user  1704 . These lookups may be based on the logical communication control list store  2506  or the queries might pull directly from the backend LDAP system. In these latter embodiments, the user manager  1704  may send CRUD requests for communication control list  2600  entries that the security system integration manager  2504  then processes. Processing may be performed within the authenticating client  2300 , translated into backend LDAP requests, or some combination thereof. 
     At this point the device  202  has been authenticated, the user  1702  has been authenticated, and together they form the active user device  1706 . This active user device  1706  has received from the authenticating client  2300  any local control lists required to operate and the user device  1706  is ready for subsequent communications with other active user devices  1706 . The next step is to initiate a session. As a preliminary matter, it is noted that heartbeat processing may be utilized in some embodiments, which is described below. 
     For explanatory purposes, the present disclosure refers to three main types of data: device, dynamic, and security. Device data consists of all BIOS and other data sufficient to uniquely identify a given device such as manufacturing ID and unique hardware identifiers. Device data may be, for example, the BIOS serial number and device MAC address. Newer devices typically use EFI (Extensible Firmware Interface) instead of BIOS; however “BIOS” terminology is used as an encapsulating term. One challenge with the BIOS serial number is that duplicate values can occur, for example blank or sequential (i.e. 123456) values, and those values might be filtered out or ignored to ensure device uniqueness. Any values not easily filtered may be appended together for that device  202  in certain embodiments. The device data may also contain the type of device (mobile, desktop, tablet) and operating system. Further, during a setup or optional installation process, values may be calculated and placed in a secure location (such as a chips Secure Memory) and utilized as part of the device data. Finally, in certain embodiments, the BIOS data can be separately hashed on both the authenticating client  2300  and device  202  sides using a device timestamp as SALT, the resulting value of which can be referred to as a BIOS hash. 
     Dynamic data includes any data that can be used to identify the location of a device. For mobile devices, this data may be GPS data in addition, or instead of, an IP address. While dynamic data is mainly used for location-based rules and for enforcing communication authorization rules, the dynamic data may be used for other purposes as well. One such other purpose is that the device timestamp may be used for synchronizing packet communications between two devices. In these embodiments, after a session has been initiated, a first user device  1706   a  might send to a second user device  1706   b  its current timestamp. The second user device  1706   b  can look at this timestamp, along with the time the packet left the first user device  1706   a , and then match those values to its own timestamp. Then the second user device  1706   b  can store the difference in timestamp values and use that variance to synchronize timestamp values in the packet headers for the two devices. This process can either be repeated or done as an option of the first user device  1706   a  over the second user device  1706   b . Synchronized timestamps may be required for many types of security approaches including, as one example, time-series algorithms which often work in the picosecond range. 
     It should be noted that where a process, data exchange, communication, and so forth are described with respect to a specific user device  1706 , those processes could be similarly applied for all constructs on a given device  202 , for a given user  1706 , or some other first class authentication member. In this regard, the approach of using groups can be utilized to mitigate processing requirements. As one example, two devices  202  exchanging timestamps can share timestamp differential values across user devices  1706 . Depending on the embodiment, user devices  1706  might also use the same modulation charts or different groups of users might share modulation approaches. As one example, all virtual machine application users (virtual users  1802 ), might utilize the same modulation charts applied, as a semantic definition, to all virtual machines. 
     Security data includes data related to the generation and exchange of keys between devices  202  and authenticating clients  2300 . In some embodiments, a unique network-level key is obtained for use by all of its authenticating clients  2300 . Other embodiments might obtain a distinct network key for each authenticating client  2300 . These network keys comprise security data and might be ties to a certificate authority such as Verisign or Thawte and used to sign data flowing to the device  202 . 
     In addition, each time an active user device  1706  reconnects to an authenticating client  2300 , the device  202  or user device  1706  may generate a new public/private key combination and, in some further embodiments, a unique timestamp is used in that key generation. In these embodiments, the active user device  1706  generates a new picosecond-level timestamp that may be optionally encrypted with the network public key and sent along with the new device  202 , or user device  1706 , public key. Additional embodiments might further encrypt the entire message with the network public key to better secure transmission. It should be noted that, as opposed to time synchronization efforts, this timestamp could be completely artificial and, in fact, used for increased security. In embodiments where every device  202  in a given system is running a virtual communications kernel  210 , the timestamp used in the headers of packets can be completely artificial and, in fact, be any date at all. The benefit of using this technique is that operating system layers, such as network or transport layer, cannot generate these types of artificial timestamps. This approach therefore ensures that a given packet was sent from a virtual communications kernel  210  and, further, it gives rise to timestamp modulation control using modulation chart techniques described previously. To this latter point, some embodiments might generate artificial timestamps based on device information, communication characteristics and so forth and utilize the timestamp as another type of packet verification and/or signature option. 
     Referring to data grouping, dynamic data requires a connection between an authenticating client  2300  and the active user device  1706 . The specific authenticating client  2300  might vary as a device changes location, or due to network loads, but the connection is still required for these embodiments. In these cases, a finite amount of time can be defined by which a given active user device  1706  needs to have sent an authenticating client  2300  an update of its dynamic data. In some embodiments, a message may need to be received by the active user device  1706  from the authenticating client  2300  on a regular basis in order to remain authenticated. Other embodiments may require updates to be received from the active user device  1706  on the authenticating client  2300  at some interval or the device  202  will have to go through re-authentication. In this latter case, the virtual communications kernel  210  initiates the re-authentication process and begins where a session key with the authenticating client  2300  is required. Maintaining the dynamic data is needed by the device  202  for session initiation as described for certain embodiments. 
     Turning now to  FIGS. 27 a  and 27 b   , examples of out-of-band session initiation are shown in accordance with various embodiments. In these examples, two devices  202  are attempting to communicate with one another or a device  202   a  is attempting to communicate with a user device  1706   b . Going one step further, both devices  202  could support user devices  1706  which has further advantages as explained later. For now, the only difference between session initiation between two devices  202  and two user devices  1706  is the required authentication process that has to occur between two devices  202  and an authentication client  2300  prior to session initiation. 
     In  FIG. 27 a   , device  202   a  sends its public active user device key  2702  to user device  1706   b . Depending on the optional utilization of modulation charts, this initial request might be encrypted in a manner known to user device  1706   b  even though this is a first time communication (device  202   a  would also need to be user device  1706   a ). This pre-known encryption might occur within a communications control list  2600  wherein different device types have different security feature sets. Depending on the embodiment, a device  202   b  might iterate through the various active users  1704   b  and look for an active user device  1706   b  that is allowed to communicate with the incoming device  202   a . In the embodiments utilizing the communications control list  2600 , the device  202   b , in finding a match, will also know the type of device and be able to access any optional secondary challenge-responses for that type of device  202   a.    
     In many embodiments, a further restriction is applied that only one active user device  1706   b  can be an end user, which represents an actual person. In these embodiments, the other active users  1704   b  may represent a range of processes and/or services but none might be allowed to accept user input, for example. When comparing active user devices  1704   b , the sending device  202   a  (or user device  1706   a ) can optionally send a request for the type of interaction, specific application, or the incoming protocol/port can be utilized for such a determination. The device  202   b  may then iterate through potential matches based on the packet header values, internal payload encryption and so forth sent from device  202   a , and can begin with the active user device  1706   b  that represents the end user. Certain embodiments might only allow matches on the end user and reject all others. Finally, some embodiments may prioritize active user devices  1706   b  to prevent a plurality of potential matches. In the cases where a device  202   b  performs local matching, the device  202   b  may then inspect its rules to determine if the incoming communication is allowed. If the rules are maintained on the authenticating client  2300 , then these processes may occur based on communications between the authenticating client  2300  and the device  202   b.    
     In the case where rules are enforced locally (i.e., at the device  202   b  or user device  1706   b  rather than the authenticating client  2300 ), when the user device  1706   b  approves a communication the user device  1706   b  sends the matching active user device&#39;s  1706   b  public key  1706 . In cases where the rules are enforced in the authenticating client  2300 , the device  202   b  can either send a range of possibly matching active user device keys  2706  or a single active user device key  2706  with which the authenticating client  2300  can perform a lookup to obtain all other active user device keys  2706  for that device  202   b  from an optionally independent data store, service, process, system or similar option. In these cases, the incoming active user device key  2702 , and any dynamic data  2704  obtained from the device  202   a  are sent from device  202   b  to the authenticating client  2300 . In terms of dynamic data  2704 , the device  202   a  either does not send specific additional information beyond what is contained in its packets, or it sends over additional parameters such as GPS location or source IP address. This latter set of optional data may be transmitted in an encrypted format that is not readable by device  202   b , but only in a format that can be decrypted by the authenticating server  2300 . Further the entire request from device  202   a  may be optionally signed by the device  202   a  and even encrypted using a network key controlled by the authenticating client  2300  in cases where the rules are enforced at the authenticating client  2300  or even device  202   b  through modulation charts or similar option described previously. In this latter embodiment, nothing unencrypted passes between two devices  202  including a public key. 
     Once the authenticating client  2300  receives the device keys  2702  and  2706  and optionally decrypts and processes any rules, dynamic data  2704  can be used to validate the device  202   a  based on data accessible to the authenticating client  2300 . Since the communication arrives on a secure transmission from device  202   b , the identity of the user device  1706   b  is already confirmed. Assuming the device  202   a  is matched and communication is authorized, the authenticating client  2300  may then generate a session key  2710  using an option such as Kerberos or its own internal key generation option to be sent to both user devices  1706 . This session key  2710  may then be copied and encrypted with the active user device public key  2702  to produce a secure session key  2710  for user device  1706   a  and the session key  2710  can be encrypted with the user device  1706   b  active user device key  2706  to create a secured session key  2708  for user device  1706   b . The authenticating client  2300  may then optionally sign the keys and transmit those keys separately to each user device  1700 . Both keys might, instead, be sent to either user device  1706   a  or  1700   b  and the receiving user device  1706  might then send the session key  2710  to the other user device  1706 . In these latter embodiments, the authenticating client  2300  might not encrypt the session key  2710  twice, or at all, and the receiving device may or may not encrypt the session key with its own or the other device&#39;s key prior to transmitting the key to the other device. In the first embodiment, each user device  1706 , in turn, decrypts the received session key  2710  using its private key and then the user device  1706   a  and  1700   b  may start securing communications based on a shared session key  2710 . Throughout the process shown in  FIGS. 27 a  and 27 b   , there is no mandatory exchange of any inline, unprotected, security information between devices  202  or user devices  1706 . 
     Referring back to the location of the virtual communications kernel  210 , the process of  FIGS. 27 a  and 27 b    can occur without operating system interference. The logical location of the virtual communications kernel  210  is important when considering a TCP handshake and its use in distributed denial of service (DDoS) attacks. Specifically, a TCP handshake involves a SYN packet being sent from one device  202  to another; a SYN ACK packet being sent in response; and then an ACK packet being sent from the first to the second device. All of these packets are exchanged before any higher-level information is exchanged between two devices  202 . These handshake packets themselves are not typically problematic, but attacks such as DDoS leverage this process multiplied many times over to overwhelm a specific series of devices or services. Since, in accordance with various embodiments disclosed herein, the virtual communications kernel  210  sits below the TCP layer and given the single package nature of session initiation, the virtual communications kernel  210  provides an option to avoid such an issue. In certain embodiments, the initial SYN packet can be routed to a secondary device  202  in a load balancing paradigm. Since the communications control kernel  210  can control all standard fields in a packet, the communication, or hop, from the initial device  202  to the load-balancing device  202  can remain invisible to outside users. Further the communication control kernel  210  can modify the outgoing communication packet  302  such that the communications packet  302  appears to be coming from the initial device  202 . In this manner, load-balancing efforts do not result in new targets for a given DDoS attack. 
     When considering the TCP handshake communication deficiencies discussed above, it should be noted how the use of the virtual communications kernel  210  in out-of-band session initiation can improve network performance. Instead of a minimum of 16 packets being exchanged in an out-of-band initiation effort that utilizes a TCP handshake, by using the virtual communications kernel  210 , only 4 packets at a minimum are required. By using the virtual communications kernel  210  and optional modulation charts, even the initial request from device  202   a  to device  202   b  can be protected. To this latter point, a modulation chart might establish one or more expected types of encryption approaches that device  202   a  needs to use prior to sending out a request. Device  202   b , using the same modulation chart—and this modulation chart can optionally be fulfilled using a range of options such as configuration files, embedded code, and so forth—will attempt to reverse the encryption approach process and, failing to do so, will result in an automatic rejection. This operation could be as simple as looking for a certain header value or as complex as a BPEL-like series of decryption steps. Even a simple header value might be the result of a complex operation such as a time-series calculation. Once the virtual communications kernel  210  is added in a session initiation process, a layered secured initiation process in enabled 
     In some embodiments, for example, the virtual communications kernel  210  transparently redirects a flood of incoming requests to other devices, which will be explained in further detail below. For now, it is noted that the virtual communications kernel  210  can forward packets without a visible network hop, which may be the result of operating system restrictions, since it is unencumbered by such restrictions. Other embodiments establish rules that ignore a flood of incoming requests, for example where repetitive requests from an external device are ignored for a certain period of time. Since there is no handshake in the above-described session initiation process, any processing impact is nominal, and the traffic is significantly reduced and the number of devices required to impact a system are greatly increased. 
       FIG. 28  illustrates a concept of a distributed authenticating client  2300 , which leads to the ability to manage different levels of security using a distributed series of devices  202  and authenticating peers  2000 . In the circles, which represent levels of security, the inner level  2806  secures the most sensitive information whereas the outer level  2800 , sometimes referred to as the edge of a network  214 , contains the least sensitive information and/or systems. These are logical constructs and not necessarily limited to a type of network  214 , an active user device  1706  location, or other such features. While some embodiments might use such distinctions, the present disclosure relates to any delineation attributed to either a first class member or the interaction of two or more first class members. For example, an executive using a mobile device from a home network  214  might still be considered to be inner level  2806  for purposes of communications security, but an outer level  2800  device in terms of resource access. 
     The ability to utilize intermediary authenticating peers  2000  in the authentication and authorization scheme enables an extremely robust and flexible security construct that can be utilized to address some fundamental issues in current RADIUS/DIAMETER solutions. One issue faced in this regard is an inability for RADIUS systems to support remote authorities and the challenges faced by DIAMETER with remote authorities given its dependence on IPsec. In each of these cases, there is no viable cross-platform way to pass a given user device  1706  from authority to authority as said device  202  interconnects through different networks  214 . Moreover, outside of providing restricted resource access, these systems do not provide a mechanism to lock down foreign user device  1706  communications. Utilizing the system in  FIG. 28  can, in effect, restrict user device  1706  access to an outer level  2800  and push the required authentication to a lower level authenticating peer  2000 . This latter component can then utilize an authenticating peer  2900  from the current authority  2906  connected to an authenticating peer  2902  located in the new authority  2908  as shown in  FIG. 29 . In this case, the two authenticating peers already have existing secure communications  2104  based on a session initiation with a trusted authenticating client  2300 . Once connected, the two peers can readily hand authentication and authorization information off for devices crossing domain boundaries. For the user device  1706   a , moving forward to or “becoming”  1700   b  as shown becomes a seamless transfer as all information is passed off proactively. These embodiments, where the appropriate authenticating peers  2000 ,  2900 ,  2902  transfer user device  1706  authentication and authorization information directly, are especially advantageous in mobile environments where longer connections to central networks  214  can result in latency issues. 
     One of the largest security holes in modern networks  214  is the ability for users  1702  to access unprotected, unmonitored resources such as those located on the web  604 . As shown in  FIG. 30 a   , these systems are often referred to as open systems  3008  where a device has access to both secure resources, such as a corporate server  3000  and unsecured resources such as on the web  604 . In these cases, the device  202  acts as a bridge that enables resources to be transferred between secure and unsecure locations and that bridge is often a conduit for malicious activity. 
       FIG. 38 b    shows a local network  214   a , which demonstrates an attempt to counter some of these gaps in security by moving beyond the fully open systems  3008  into a partially open system  3010  that utilizes a gateway server  3012  to monitor traffic. Even supposing the gateway server  2012  is able to properly monitor traffic, however, there are two common use cases that break this type of system. First, as denoted by the mobile user  3004  example, many local networks  214   a  are supporting BYOD (bring your own device) implementations, where users can bring any device they desire into the local network  214   a . Very often, users will connect via their phone carrier&#39;s signal and, even more concerning, there is little to no ability for modern LDAP to enforce any level of differential security on these devices. The second use case is that of a home user  3006  connecting through an option such as a virtual private network (VPN). This issue provides a twofold challenge with the first being that a user can run a VPN application while simultaneously running an unsecured application such as a web browser. Again, this deficiency results in a bridge through which intruders can gain remote access to a local network  214   a . The second issue is that a user  1702  can turn off VPN protection. Thus, even if a VPN implementation somehow prevented other applications from running, the user can simply shut down the VPN, turn on an insecure application and possibly download malicious code. The next time the VPN is turned on, that code gains access to the secured local network  214   a  directly through the VPN. 
     In order to counter these issues, embodiments of the present disclosure provide a virtual communications kernel  210  that is conceptually shown within the OSI stack in  FIGS. 31 and 32 .  FIG. 31  shows a conceptualization of the virtual communications kernel  210  in which the virtual communications kernel  210  is initiated prior to the upper level layers  204 . These types of initializations are often found in pre-boot loading techniques, which will be understood by one skilled in the art. Once the virtual communications kernel  210  is running, with its own resources separate and distinct from the upper level layers  204 , the upper level layers  204  are launched. This enables the virtual communications kernel  210  to act as a barrier between the upper level layers  204  and the network  214 .  FIG. 32  shows an alternative embodiment where the virtual communications kernel  210  exists within the upper level layers  204 . As described previously, while hosted within the upper level layers  204 , packets captured by the virtual communications kernel  210  are out of scope of the upper level layers  204 . 
     The level at which the virtual communications kernel  210  functions enables the virtual communications kernel  210  to provide communications security beyond the control of a user. In some embodiments, this type of virtual communications kernel  210  might be fulfilled using a possible plurality of drivers and even further embodiments might run protected services or drivers that cannot be turned off without administrative access. To this end, embodiments of the present disclosure relate to an always-on security model that can run across all communications on a given device. This level of always-on, pervasive security can be applied across all devices in an enterprise to create, in certain embodiments, a closed system  3302  as shown in  FIG. 33 . In this case, all external communications pass through a virtualization gateway  3300 . This includes both communications intended for external locations, such as the web  604 , and, in some embodiments, this includes all communications from devices not physically on a local network  214   a  attempting to access resources on that local network  214   a . This latter requirement is optional to the definition of a closed system  3302  and, even in these embodiments, direct communications—such as the connection from the home user  3006  to the mobile user  3004 —is still possible. 
     The virtualization gateway  3300  is a logical construct that might be fulfilled in a range of ways depending on a given embodiment. Some embodiments will utilize an existing gateway server and add a virtual communications kernel  210  to that gateway server. In these embodiments, the virtual communications kernel  210  might act to fulfill encryption requirements or it might be used to enhance communications monitoring and control. As will be described in a subsequent section, the virtual communications kernel  210  can be employed in a variety of manners for enhanced gateway functionality. Other embodiments might utilize a range of devices, similar to the authenticating peer  2000 , to fulfill gateway requirements without requiring a roundtrip to a local network  214   a . In these embodiments, a series of active user devices can support larger communication control list to control and manage internal and external communications. Outer level  2800  connections, such as remote devices, can be handled by an authenticating peer  2000  acting in the role of a virtualization gateway  3300  as one example. While roundtrips to the central systems might be required for options such as remote access to central resources or novel requests not handled in an authentication peer  2000 , utilizing the virtual communications kernel  210  for multiple purposes results in an advanced ability for a distributed virtualization gateway architecture. 
     Some providers in the current market provide “bring your own device” (BYOD) options, sometimes referred to as overlay networks. These overlay networks often rely on a series of external gateways to control the flow of information in an enterprise. The gateway interactions are very intrusive for users—typically requiring logins to each gateway—and are often bottlenecks for data throughput. In contrast, the present invention provides an underlay network wherein the gateway functionality can be distributed in certain embodiments to each device  202 . Further since options such as the virtual communications kernel  202  can operate transparently to users, devices and applications, this underlay network does not require user interaction. In certain embodiments, the always-on, invisible, underlay network provides critical enterprise communications protected with no unwanted disruptions. 
     In terms of ubiquitous communications security, the virtual communications kernel  210  can function beyond the purview of an end user and be controlled through centralized administrative techniques as described previously. Along these lines, the virtual communications kernel  210  can be configured to process all packets across all ports for all destination IP addresses from every application or any subset thereof. Various embodiments may implement virtual communications kernel  210  in an end user manner, a centralized manner, or a combination of the two. For example, a given embodiment might provide a centrally-controlled option to run the virtual communications kernel  210  in something akin to silent mode. In this mode, the virtual communications kernel  210  might be centrally administrated through communication control lists  2600  and modulation charts and may not provide any interface to an active user device  1706 . In this same optional embodiment, the centrally controlled configuration might be instead set to something akin to an active role. 
     In this active role, there may exist optional control lists  2600  and even modulation charts; however, certain embodiments provide a more intrusive active user device  1706  presence. For example, certain embodiments might enable complete control by the active end user device where a chat-like interface is presented to the active end user device through which the active end user device is able to accept/deny/invite other active end user devices into a secure communication. Some embodiments might then utilize some level of encryption approaches based on the active end user device connection whereas others might enable the active user devices  1706  to further determine which applications or ports to protect. Certain embodiments might enable communication wrapping, to be described in a subsequent section or other additional obfuscation features such as cloud bouncing as shown in  FIG. 34 . 
     A cloud  608  is a concept understood to one skilled in the art. This construct can refer to a large range of devices  202 , ranging from a single server in one location to a global network of connected devices  202 . Within this cloud, as shown in  FIG. 34 , virtualized cloud peers  3400  can be placed in order to aid communications in a number of important manners. Some embodiments may utilize this cloud  608  architecture to provide an out-of-band communication pathway for enhanced security. Depending on the complexity of the embodiment, each mobile user  3004 , representing an active user device  1706 , would have separately initialized a session with one another as well as one or more virtualized cloud peers  3400 . At this point, these embodiments can send data between the two mobile users  3004  divided amongst the two paths. The delineation of what data is sent over which path can be made based on any characteristic of a packet such as the packet size, protocol used, CRC value, encryption approach implemented, and/or results of an applied approach and so forth. Some embodiments may use defined business rules, whereas others might utilize a random generator in order to determine which packets traverse which path. The same options for creating and determining encryption modulations can be used in this regard and, in some embodiments, the use of the cloud-based path or the direct channel might be included as part of a modulation sequence. 
     Other embodiments may only utilize a cloud-based path as is shown in  FIG. 35 . While a mobile user  3004   b  is shown with unprotected communications  3500 , that is for the sake of explanation and does not denote any sort of restriction. By using a cloud  604  path, users can obtain a greater degree of anonymity than they might otherwise obtain through direct communications. As one example, the virtualized cloud peers  3400  can act in numerous roles from authenticating client  2300  to authenticating peer  2000  to a proxy server. In this latter regard, a user might be able to appear to a target device  202  as if they are in a location different from their physical location. In these embodiments, a user may wish to appear as if they are visiting a given device  202  from England when they are actually physically located in the United States. If the cloud  604 , which can be comprised of a global network, has virtualized cloud peers  3400  in England, then a given communication path from the mobile user  3004  can be routed through that peer in England acting in the role of a proxy server. 
     This latter role, however, can extend beyond that of a traditional proxy server where the proxy server utilizes pre-existing fields to denote its presence. Instead, based on the virtual communications kernel&#39;s  210  ability to completely unwind and rewind a packet, the cloud peer  3400  can change the actual source IP address in a transparent manner. Then, using an operation manager  1104  with access, either directly or via static pointers or other similar options, to sufficient memory resources, the virtual communications kernel  210  can store sufficient information about the communication stream to perform a reverse translation process for responses back from the target device  202 . 
       FIG. 35  demonstrates another type of communication that can be enabled, which is referred to herein as a “partially protected communication.” In this case, mobile user  3004   b  is not an active user device  1706  and does not have a virtual communications kernel  210 . As such, this mobile user  3004   b  is not able to handle any communications secured using a virtual communications kernel  210 , which prevents direct secure communications. That stated, using virtualized cloud peers  3400 , which are any device running in a cloud that contain the virtual communications kernel  210 , the mobile user  3004   a  can participate in partially protected communications and even generate communication control protection and encryption modulations based on this type of communication. The main advantage to this system is the reduction in the amount of traffic that is susceptible to infiltration. Instead of participating in completely unprotected communications, only the final transmission to the mobile user  3004   b  is susceptible to attack. Given that even direct communications are often routed through various intermediate systems, this is a significant enhancement over unprotected communications  3500 . 
     Additionally, from an administrative perspective, the virtualized cloud peers  3400  can act in a deep packet inspection role, either as part of a gateway server or separate, in order to provide an additional layer of security. Other embodiments may use either centrally- or user-generated policies to control modulation charts or communication control lists  2600  to restrict partially protected communications both in terms of what is allowed into a given active user device  1706  and what resources any application  208  is allowed to utilize when participating in a communications session and can differentiate based on the level of protection. 
     In terms of interacting with either a virtualized gateway  3300  or a virtualized cloud peer  3400 , the virtual communications kernel  210  on the gateway or peer  3300 ,  3400  can transparently redirect an incoming request based on the presence of a virtual communications kernel  210  on the participating device  202  (e.g., a device of mobile user  3004 ). If a request is coming from an unknown device  202 , for example, the gateway or peer  3300 ,  3400  might present a general marketing site asking the user to register their device or some such general audience message or the request might be rejected outright as one example. If the same gateway or peer  3300 ,  3400  receives a communication from an active user device  1706 , on the other hand, it might respond with secure extranet data or direct access to an intended active user device  1706  elsewhere in the system. 
     While the described pattern of session initiation, as well as the communication control list  2600 , provides the ability to identify other active user devices  1706 ,  FIG. 36  demonstrates a closed system  3302  that enjoys another level of protection from intrusion. In a closed system  3302 , only the virtualized gateways  3300  would ever handle unknown packet streams  3600 . In some embodiments, even the initial session initiation request between two active user devices  1706  can be encrypted based on a modulation chart. Even in embodiments where the session initiation is not encrypted, the format of such a request is defined and thus unprotected communications coming into an active user device  1706  that does not follow that format can be proactively identified prior to that communication ever reaching the operating system. This feature supports a powerful counter-intrusion capability which aims to both prevent the spread of unauthorized data, such as malware, and to stop zero day network infiltration. It should be noted that the virtual gateways  3300  can be enforced across selected devices  202 , all devices  202  or independent devices  202  depending on the embodiment. Certain embodiments will further include active user device constructs and active user device application constructs to restrict and/or isolate information from unprotected device  202  communications to protect resources such as file systems, processors and memory. 
     Previously, networks  214  had limited options in terms of responding to attacks and, for the most part, those responses were limited to defense. Although subsequent forensic activities can be utilized to identify and respond to hackers, the upfront response is, for the most part, never offensive in nature. By removing the operating system from the response equation, embodiments of the present disclosure provide the ability to effect offensive retaliations to intrusion attempts. This is based on the fact that, even as low as the TCP level, operating system-dependent responses are always visible as network hops. Thus, an intruder can see in real time that they are no longer on a targeted device and they can escape prior to any actions taking place. The presently disclosed virtual communications kernel  210 , on the other hand, can transparently redirect traffic without incurring a network hop, due to its ability to modify a communications packet  302  while still keeping the packet structurally intact. The ability to unwind a packet  302 —which is disclosed as being used to perform operations on the base datagram  110  at least in some embodiments—can also be used to clone and send or redirect incoming communications packets  302  to other locations as described previously. In this regard,  FIG. 37  shows the main packet  302  can be deleted from an unknown packet stream  3600 , which originates from intruder  3704 , being received at a user device  1706 . The virtual communications kernel  210  of the user device  1706 , in accordance with various embodiments, may delete these incoming packets  302  while generating clones of the unknown packet stream  3600  to be transparently sent to any other location desired (e.g., honeypot  3700 , dark net  3702 , or virtualization gateway  3300 ). To the would-be intruder  3704 , there is no evidence that any redirection is occurring and thus they have no ability to detect any counter responses. The present disclosure does not specifically relate to actual counter-intrusion techniques, such as honeypots  3700 , dark nets  3702  and reverse trace back efforts, rather these are provided as examples with which the disclosed framework of redirection for the purpose of implementing a counter-intrusion technique can be utilized. That stated, the virtual communications kernel  210  is able to modify existing header values to make packets in one location look as if they came from another. To this end, responses from honeypots  3700 , dark nets  3702  and so forth can be disguised as responses from an initial point of attack. 
       FIG. 38  demonstrates another example of redirection in accordance with various embodiments. In particular,  FIG. 38  shows a distributed denial of service (DDoS) protection option. The challenge in current defenses is that even options such as load balancers are visible and thus susceptible to DDoS attacks based on TCP handshake weaknesses. Given that the virtual communications kernel  210  (included in the virtualization gateway  3300  shown) is logically situated below the TCP layer, it both overcomes handshake limitations and can transparently spin up on demand servers  3800  to overcome saturation attempts. Since the redirection is invisible to the attackers  3704 , each on demand virtualized gateway  3800  is invisible to attackers  3704  and thus will not become a new target. In this manner, a DDoS attack can be rendered harmless while still maintaining full service capabilities. When combined with the cloud  604  disclosures, this DDoS defense can be further distributed making an effective DDoS attack virtually impossible. 
     The ability to provide transparent redirection is not just restricted to counter-intrusion applications and can, in fact, help to address a fundamental flaw in accounting systems. To this end, current accounting operations are resource provider-centric with the general principle being that a resource provider sends a notification to an accounting server whenever it starts and stops providing a resource to a given user. Some accounting systems will also utilize intermediate accounting messages to overcome issues such as service disruption. That stated, there is currently no concept of guaranteed delivery, which is becoming more important as more intermittent/mobile environments are being employed and central resources are spread ever further from the central accounting/resource centers. 
     To this end, a prior example focused on how quality of service (QoS) might be recorded in one manner by a resource provider such as a streaming server and yet received in a completely different manner by a resource consumer due to issues such as network saturation. While current accounting issues cannot accommodate this guaranteed delivery requirement, embodiments of the present disclosure can be utilized to this end in a variety of possible ways. First, as shown in  FIG. 39 , a user device  1706   a  may clone all incoming traffic and send those cloned packets  3900  to either an accounting server  3912  or, as in the case of packet pointer security, to a big data analytics system  3904  for processing. In terms of the accounting server  3912  target itself, given that every user and device can be combined together using the new authentication approach, multiple devices  3904 ,  3906 ,  3908  can comprise one logical accounting server  3912 . This enables a distributed accounting system where data can be optionally rolled up as it progresses from outer to inner accounting boundaries. Using distinct modulation charts and communication control lists  2600 , the entire logical accounting server  3912  construct can be logically isolated with tightly controlled input and output options. 
     Other embodiments might utilize the operation manager  1104  in each active user device  1706   b  described previously to perform some level of upfront processing. In the QoS example, the rate at which packets successfully enter the device, filtering out and/or recording retransmission packets, might be directly measured in real time. The counters provided in  FIG. 39  are exemplary. Any aspect of the communication stream  510  can be analyzed in any way required for accounting purposes. The virtual communications kernel  210  in device  202   b  can then send out accounting messages  3902  to the logical accounting server construct  3912 . 
     Another challenge faced by accounting systems relates to limitations in provable accounting between authorities. As more and more devices interact with resources, for example bandwidth, on remote authority networks, home authorities are increasingly reliant on these remote authorities for accurate accounting. That stated, if a given user  1702  disagrees with the resources charged, total number of minutes as one example, the home authority has no resource to prove this usage. The home authority has no independent mechanism in place to verify how accurate remote authority accounting is and, even if accurate, the way in which a remote authority accounts for various resources might differ from the home authority&#39;s own accounting. As one possible issue, a delineation between data versus voice traffic might be defined by one authority based on the ports used by the other authority based on application. 
     As described previously in  FIG. 29 , two authenticating peers  2900  and  2902  are able to maintain long-running communications and can act as a bridge thus extending the logical accounting server construct defined herein even across authority boundaries. In this latter embodiment, the device  202   b  is able to directly transmit accounting messages to an accounting peer at some level through other accounting peers. This is not to suggest that the accounting peers  2900  and  2902  cannot themselves be authenticating peers; indeed, they may be since these references are logical, rather than physical, definitions. 
     When considering embodiments for accounting where the device  202   a  sends cloned packets  3900  to an accounting peer  3902 , it is noted that these encrypted packets and/or packet statistics such as throughput rates would need to be potentially decrypted before any analytics can be applied. Further, in many larger networks, system and network administrative tools require full access to data flowing between devices and, as such, require data to be unencrypted. In fact, numerous current technologies—including VPN solutions and IPsec transport mode—typically involve significant one-off integration efforts. In the case of IPsec transport mode, even integration efforts fail and administrators are forced to turn off encryption in order to use network and system administrative tools. Considering that encryption changes system and network dynamics, system and network administrators are often unable to gain accurate pictures of their networks. 
     In order to support these needs,  FIG. 40  shows certain embodiments that utilize an option that is referred to herein as a super peer  4000 ,  4006 . Super peers  4100  in general as shown in  FIGS. 41 a  and 41 b   , are able to decrypt all communications flowing between any two monitored devices. In  FIG. 41 a   , the super peer  4100  is logically situated between all communications with an authenticating client  2300  (which could optionally be an authenticating peer  2300 ) in order to monitor all traffic. Other embodiments might only flow traffic directly between monitored devices  4102  as shown in  FIG. 41   b.    
     These super peers  4000 ,  4006 , depending on the embodiment, can be of two general types. The first type is an open super peer  4000 , which decrypts all traffic and passes that traffic to the operating system. Depending on the embodiment, the open super peer  4000  either clones the packets and sends one copy to the intended active user device  1706  or waits to obtain the packets from the operating system, re-encrypt the packets, and then sends those packets to the destination active user device  1706 . Certain of these steps may be combined in some embodiments. To this latter point, an administrator might use cloning by default, but either apply this operation to all traffic or apply the operation for a certain subset of traffic. In terms of control and configuration, some embodiments might enable the remote administration of a super peer  4000  whereas other embodiments will only allow direct setup and configuration of a super peer  4000  on the physical device  202 . 
     Depending on the embodiment, the configuration process may require a user  1702  to logically group all known processes on a given super peer  4000  and  4006 . While the categorization is flexible and can be tied to any number of communication control list  2600  options, one possible set of categories is provided in  FIG. 40 . In this case, the open super peer  4000  has been configured such that applications are either allowed to run as active applications  4002  or are shut down and/or blocked from sending and receiving data and thus are designated inactive applications  4004 . Some embodiments will enable a super peer  4000  to have a virtual communications kernel  210  that can be turned on or off, whereas others will require always-on functionality. In these latter embodiments, the inactive application  4004  designation would permanently disable and/or block communications for an application that has that label. Leveraging these features, certain embodiments might automatically categorize all unknown/new processes as inactive applications  4004  for enhanced security purposes. An interface on either a central administrative construct&#39;s system or directly on the device  202  (or user device  1706 ) can be used to highlight these new processes in turn. 
     The other type of super peer is the restricted super peer  4006 , which includes a super peer manager  4008 . In these peers  4006 , no traffic is decrypted by default, but a user  1702  can use the super peer manager  4008  to access one or more active user device  1706  communications at any given time. Some embodiments may limit to the total number of active user devices  1706  that can be unlocked, restrict unlocking to one primary active user device  1706  and an optionally limited number of connected active user devices  1706 , and so forth. Once unlocked, the optional categorization of applications as described previously can be utilized. A further embodiment might enable unlocking features by security level such that, for example, a secret clearance can only unlock secret or general access communications but not, furthering this example, top secret communications. This latter restriction can be applied alongside other described features. 
     In order for these peers  4000 ,  4006  to function as described above, access to session keys and any modulation charts for all monitored active user devices  1706  is needed. In addition, changes in dynamic user data should be updated on the super peer  4000 ,  4006 . To this end, a super peer  4000 ,  4006  first needs to authenticate through the authenticating client  2300 . Depending on the embodiment, the backend authenticating server  2302  might utilize a range of challenges responses to thoroughly authenticate a given super peer  4000 ,  4006 . Once authenticated, the super peer  4000 ,  4006  creates a long-running session with the authenticating client  2300 . Depending on the embodiment, this long-running session might utilize a distinct modulation chart, utilize protocol wrapping, and might even need to recycle after certain intervals. Given that the authenticating client or peer  2300 ,  2000  are providing session keys, the process for enabling a super peer  4000 ,  4006  can be controlled through this latter connection. Some embodiments, especially those using open super peers  4000 , will provide the session key to the super peer  4000 ,  4006  as the keys are generated. Depending on the embodiment, a super peer  4000 ,  4006  public key might be used to encrypt the session key for additional security. 
     Other embodiments might utilize an on-demand system where a given active user device  1706  communication&#39;s session key is not released until the super peer  4000 ,  4006  makes an explicit request for access to that communication stream. These requests might be made using any identifying dynamic data for a given active user device  1706 . Likewise, some embodiments will provide all data and encryption options for each active user device  1706  as the user devices  1706  become active. Other embodiments will send a restricted set of data, for example just the identifying dynamic data, and others will use these options in an on demand manner 
     For advanced security, some embodiments might define a given super node  4000 ,  4006  as a series of devices  202  instead of one device. Within this context, a subset of devices might be active at any one time with some sort of rotation being used to change activations. The change in active devices  202  may occur within the configuration manager  1102  on each device, based of rules centrally administrated and enforced either on each super peer  4000 ,  4006  or on the connected authenticated client or peer  2300 ,  2000 . The change in activation might be in response to resource usage, and not security or not just due to security, and can be a manual process in addition to or instead of an automated process. 
     In terms of determining which devices are being monitored by a given super node, some embodiments will utilize an administrative console located either on the super peer  4000 ,  4006 , on the authenticating client or peer  2300 ,  2000 , or on a separate server that optionally controls LDAP security. Other embodiments will utilize a nearest neighbor approach where the closest devices  202  to a given super peer  4000 ,  4006  are captured and assigned to that super peer  4000 ,  4006 . Other embodiments might utilize an approach where any communications accessible by a super peer  4000 ,  4006  can be used to start monitoring a user device  1706 . Some embodiments will use some sort of boundary system to prevent more than one super peer  4000 ,  4006  per user device  1706  while others will allow varying levels of overlap. In the boundary-based embodiments, options such as device proximity, device type, protocols being used and location in a network and so forth can be used to determine which of a possible plurality of super peers  4000 ,  4006  can monitor a given user device  1706 . Yet other embodiments will treat open  4000  and restricted  4006  super nodes are separate entities and may even require at least one of each for every communications stream. 
     When communicating over an insecure network such as the Internet, active user devices  1706  also have the ability to utilize protocol wrapping in order to further obfuscate traffic. This process is shown in  FIG. 42  where the operation manager  1104  within the virtual communications kernel  210  first collects all of the original packets  4200  for a given original stream  4202 . Each packet is unwound and its base datagram  110  is extracted. Once all of the packets have been captured for a given original stream  4202 , and all base datagrams  110  extracted and appended together, the operation manager  1104  can packetize the base datagram  110  in another protocol  4204 . Optional embodiments might apply encryption approaches to the base datagram either for each original packet  4200  or on the extracted and reconstructed base datagram  4200  of both. Once packetized, each the virtualized datagrams  124  might also have an encryption approach applied to it. The packetization process then returns a set of new packets  4206  that the operations manager  1104  sends back to the packet manager  1106  for transmission to a target active user device  1706  based on the destination of the original stream  4202 . Other embodiments will translate one protocol  4204  into another protocol  4204  packet on a packet  302  by packet  302  basis. These embodiments are useful when the base datagram  110  can be the same length in each packet  302  type. 
     On the other end, this process is reversed to obtain the original base datagram  110  and then to re-packetize the datagram using the original protocol. In order to know what streams and/or protocols to use, the active user devices  1706  might rely on modulation charts with protocol swapping as another option, the sending active user device  1706  might embed flags in its optional virtualization header  122 , or some combination of these options. In these latter embodiments, flags might aid in determining the current and original protocols as well as the affected packets. Alternative embodiments might use a flag to denote the use of protocol swapping with all swapping following the same pattern based on either the current protocol, for example FTP goes with HTTP, TCP goes with SCTP, and so forth, or all protocols being statically mapped to one original protocol. In yet other embodiments, the determination of protocols might be based on options such as IP addresses, ports utilized, or even duration, message size, and time of day. A flag might indicate the use of an alternative modulation chart just for protocol swapping purposes. 
     In terms of ports used, a lightweight mechanism that might be used either in conjunction or instead of protocol swapping, depending on the embodiment, is the concept of port swapping. Since a virtual communications kernel  210  sits on both ends of the communication stream, active user devices  1706  can agree to switch ports for any communication stream for any reason. Options may include such things as time of day, protocol, location of one user device  1706  or the other (or both in some combination), and so forth. Port swapping can be randomized with a flag being sent across to denote impending switches or be based on controlled switching stemming from embedded code or modulation chart efforts. 
     Embodiments directed to port swapping obviate vulnerabilities found in prior port scanning and firewall technologies. Current firewalls contain two types of ports—open and closed. Given that many applications utilize the same ports across devices, would-be intruders can gain a sophisticated understanding of a given device&#39;s system by simply attempting to access every port on that device. Since the firewall will either immediately reject a request based on a closed port or eventually reject a request based on an open port with unwarranted communications, intruders use this process of port scanning to get a complete picture of the device with little risk. 
     Embodiments of the present disclosure include a new type of port, referred to as a “redirect port,” which is capable of transparently redirecting traffic. Thus, when a would-be intruder scans a redirect port and thinks the port is open, the intruder is actually redirected in an invisible manner, as has been described above. Thus, embodiments of the present disclosure utilizing a redirect port are able to utilize three types of ports to, at the very least, obscure the ability of an outsider to gain knowledge of the internal systems and processes of a given, protected device. Some embodiments further utilize port swapping to randomly change ports, thus transforming currently static firewall pictures into a dynamic firewall design. 
     This dynamic firewall capability, where the disclosed redirect ports are combined with the disclosed port swapping methodology, especially when combined with communication control list  2600  features, provides an improved level of protection for each active user device  1706  relative to prior practices. Further, implementing dynamic firewalls on virtualization gateways  3300  enables highly secure defenses for entire networks. To this end, closed systems  3302  are able to extend beyond geographic and platform boundaries. By modifying protocols and ports, embedding firewall level security within each user device, and encrypting data, secure communications can be established even on previously insecure networks. 
     Certain embodiments relate to a private Internet community  4300  as shown in  FIG. 43 a   . By utilizing a group-level shared secret, represented as a community key  4304 , members  4302  can participate in numerous groups without fear of data being shared across communities  4300 . Although some embodiments anticipate sufficient protection based on point-to-point communications security, the embodiments of  FIGS. 43 a , 43 b    leverage the ability to generate community keys  4304  to provide an additional layer of protection. To this end, during the authentication process described previously, the authenticating client  2300  (or peer  2000 ) can utilize a range of optional rules in order to generate and distribute community keys  4304 . Alternatively, in those embodiments where the virtual communications kernel  210  is extended to provide a user interface, the formation of a new group in the interface may enable the creation of a community key  4304  as shown in  FIG. 43   b.    
     The user interface  4306  shows the hypothetical result of a user (not shown) assigning user devices  1706  to different communities  4300  or rejecting an incoming request. This interface  4306  is exemplary and does not restrict what the interface  4306  may or may not include. The interface  4306  may exist on any viable device and, by itself, be presented through any desktop, mobile, web, or other technology utilized to present interactive features to a user. The communities  4300 , depending on the embodiment, might be generated through a central system, such as a controlling extranet server or authenticating peer  2000  (client  2300 ). Other embodiments might utilize a controlling peer approach where one user device  1706  is allowed to make the communities  4300 . This might be useful, as one example, when a subscriber obtains a subscription allowing a variable number of users. The purchaser would then be able to control the groups and even the memberships depending on the embodiment. Other embodiments could allow peer-based communities  4300  to be created such that a new user device  1706  connection also includes a community invitation or an automatic community  4300  creation. 
     Other embodiments may generate communities  4300  without any user device  1706  interaction or even awareness. As such, communities  4300  might be assigned as attributes to a first-class authentication member and/or assigned through business rules that can be run at any point including, but not limited to, authentication, session initiation, ongoing session handling, and so forth. These latter embodiments can support a system such as the one described in  FIG. 44 . In this figure, a hypothetical enterprise is configured along the lines of business units (e.g. accountant  4408 ) and a hierarchy (e.g. manager  4410  and VP  4412 ). It should be noted that communication control lists  2600  can be used to handle these types of delineations and, in fact, communications control lists  2600  can be further used to require, authorize, and determine/control the generation of various keys. 
     Still referring to  FIG. 44 , the explanatory embodiment—either through a communications control list  2600 , authentication/initiation rules processing, and so forth—may require up to two keys in order to authorize and secure communications. In this latter regard, the keys themselves might be required by the virtual communications kernel  210 , for example to enable its underlying encryption approaches. These latter requirements might then result in authentication processes and virtual communications kernel  210  encryption working together to more fully secure an enterprise. As shown, the network key  4400  represents a general key that identifies the entire enterprise and would be equivalent to the community keys  4304  described in  FIG. 43 a   . In these cases, the keys might be generated using a private function on any one of the devices involved in modulation chart management, session initiation, user device authentications, and so forth. In some of these embodiments, the network key  4400  itself is a range of entries into a formula that can generate a key at runtime. This latter feature enables the dynamic insertion of data points such as subnets, domain names, and so forth to further protect the actual key and open validation options accordingly. As one example, a device in one domain might generate a network key  4400  and send that key  4400  to a device in the same domain. The receiving device might then generate the same network key  4400  and compare its results to the incoming key  4400  to validate the remote device. 
     Alternatively, the network key  4400  might be generated by a third party and used without modification through the community or enterprise or the key might by generated only by the authenticating client ( 2300 ) or server ( 2302 ) and controlled centrally. Regardless of the point of origin, this key  4400  is used to uniquely identify and secure communications as warranted across the enterprise or community. As shown, the two accountants  4408  are then able to communicate because both have an accountant key  4402 . The bottom accountant  4408 , however, is unable to initiate a session with the manager  4410  and is unable to read the communication between the manager  4410  and the VP  4412  due to a lack of a sufficient key. 
     The manager  4410 , however, is able to initiate a session with the accountant  4408  due to the manager key  4404 . This ability introduces the concept of a key hierarchy, in which lower order keys are used to create higher level keys. By including one key within the context of another, the lower key can thus be generated from the higher level key. Alternative embodiments may utilize a lookup process where the keys are used to look up data to either be used in place of the keys (e.g., for an encryption approach) or used once the incoming key has been cleared for use. In an example of the latter embodiment, the accountant  4408  might send the incoming manager key  4404  to an authenticating client  2300  and, once the authenticating client  2300  authenticates the manager  4410 , a session key might be sent back to the accountant  4408  and the manager  4410  as part of the previously described session initiation process. 
     This key-based authentication approach resides on top of the virtual communications kernel  210  packet protection, as described previously, in certain embodiments. This ability to protect the packets independently ensures the safe delivery of keys  4400  between devices  202 . 
     Referring now to  FIG. 45 , a system for protecting IoT devices connected to one or more local systems is depicted. In this diagram, a local system (i.e., any subnet and the devices local to that subnet) comprises a Local Domain Server (“LDC”)  4500 . A subnet can be defined as a network of connected devices wherein all connections are local. Alternatively, a subnet may be more logical such as is the case when a cloud is used to connect directly with other devices  202  across a possible range of locations. The LDC  4500  may be comprised of one or more databases, such as a domain database  4510 , a device agent  4520 , and a virtual management module  4530 . The device agent  4520  is a logical construct that handles both the virtual communications kernel  210  and any other interactions required for a device to function within this invention. The local system may comprise an internal security/policy engine configured to monitor packet flow and transmission of critical data. As each device agent  4520  establishes secure communication with the LDC  4500 , and as the LDC  4500  has the ability to send updates to all IoT devices associated with the local system, only authorized peer device communications may be allowed depending on the embodiment. Further illustration of these principles is provided in the following paragraphs. 
     In embodiments, the device agent(s)  4520  facilitates communications with IoT devices in the local system. Preferably, each IoT device in a local system is configured with at least one device agent  4520  through a process that is invisible to, and in certain embodiments precedes the activation of, other systems and applications. In certain embodiments, the device agent  4520  is installed as a driver or otherwise as a no-UI application; as a pre-Boot or chip-based process resides outside of the operating system; as a new BIOS alternative; as a user mode application with access to low level communications or some other variant as required. This allows the device agent  4520  to acquire and process packets logically outside of an operating system, and preferably in a low-level application. The acquisition of packets may be achieved through a “shim” (i.e., NDIS for Windows-based applications or IP Tables for a Linux-based application) configured to grab packets before they exit or as they enter the kernel described in conjunction with  FIG. 49  below. The device agent  4520  also preferably comprises an internal self-check protocol to ensure that a device key or device ID is valid, or to ensure that the latest version of any policies/modules maintained by the LDC  4500  are enforced for all peer-based communications. 
     While each device agent  4520 , in certain embodiments, is configured to immediately establish a secure connection with the associated LDC  4500 , the domain database  4510  of the LDC  4500  may also communicate and send updates (for example, via BUS commands) to other domain databases located outside the LDC  4500 , as shown in  FIG. 45 . The LDC  4500  may be installed on either a new device or an existing device. In a preferred embodiment, the LDC  4500  facilitates out-of-band communications by way of a filter, which is specially configured to filter application traffic and undesired packets from the LDC  4500 . The filter in one embodiment is configured to apply only to specific packet characteristics, such as TCP/IP header value, source IP, port, etc. 
     In another embodiment, the LDC  4500  is configured to inject a unique identifier into each packet payload, thereby creating a virtual band for communications routed by the LDC  4500 . The LDC  4500  may be coupled to a virtual management module  4530  that may further provide a visual interface, and which may further comprise one or more engines, such as a policy engine or threat analytics engine. Additional engines and/or modules may be provided with the LDC  4500 , including those described in detail below. 
     The system of  FIG. 45  may be configured to operate in connection with an event bus or equivalent bus-based command and control system. In embodiments, the event bus, or other commands and control or replication system, is configured to send and receive data between local systems, or alternatively between known devices in a local system. In embodiments, an event manager distributes messages (command and control) to separately update the LDC database  4510 . Alternatively, the event manager may communicate directly with a specific IoT device or a device agent  4520 . The event bus topology enables the event manager to receive and distribute messages (binary or text). Simultaneously or near-simultaneously, the virtual management module  4530  records the transmission of messages and any errors that are received by the event manager. Messages that are sent are preferably encrypted, as described in greater detail below. Other embodiments might rely on database-level replication systems which can, optionally, utilize the virtual communications kernel  210  to secure the transmission of data. 
     During communications with any IoT devices on the local system, each IoT device may establish a connection with the LDC  4500 , in the first instance, via the device agent  4520 . These are referred to as “LDC First” communications. Alternatively, or in addition to LDC First, peer-to-peer device communication may occur by each device obtaining a “ticket” from the LDC  4500 , and each transaction is recorded in the domain database. This serves as a transaction ledger within the LDC  4500 , which in turn allows the LDC  4500  to modify a device ticket at any time. Illustration of this communication is shown in  FIG. 46 . 
     As shown in  FIG. 46 , a first IoT device may obtain a device ticket from the device agent  4520 . Simultaneously or sequentially, a second IoT device may obtain a separate device ticket from the device agent  4520 . According to one embodiment, the first and second IoT devices may exchange the device tickets obtained from the device agent  4520 , and may further authenticate the device tickets exchanged with the LDC  4500 . In this manner, both the first and second IoT device communication paths may be verified by the device agent  4520 , and further data security policies may be applied, such as the security policies described below. Some embodiments utilize one device ticket for all device  202  communications, whereas other embodiments require a separate ticket for each communication interaction. These latter embodiments are advantageous for simplifying distributed ledger transactions as each entry can be quickly identified by the device tickets involved. 
     The communications routed through the LDC  4500  are preferably all encrypted using a specially configured blockchain-based encryption protocol. Modern blockchain efforts attempt to authenticate users, devices and transactions all in one interaction. This approach is supposed to maintain anonymity between devices  202  and users while still securing the actual transaction. In order to obtain this protection, extremely complex mathematical equations are utilized, which is not advantageous to IoT environments. 
     In contrast, the current invention provides embodiments wherein the devices are authenticated independently, and preferably prior to any transactions. In certain embodiments, this type of secured communications can occur between an exemplary requesting device  202  and an LDC  4500 . In these cases, the requesting device will have been provisioned with a local LDC public key, as described in subsequent sections, as well as a number of optional encryption options through a modulation chart optionally nested within a communications control list  2600 . The requesting device will then generate a random shared session secret value and use the LDC public key and one of a possible plurality of encryption options to encrypt that shared session secret. Separately, the requesting device will encrypt its device ID, to be described in a subsequent section, with its device private key. The encrypted device ID, encrypted shared session secret and the ordinal reference to the encryption used for both are then, in certain embodiments, transmitted to the target LDC  4500 . 
     The LDC  4500  will use its private key and the ordinal reference to the appropriate encryption process to decrypt the shared session secret and the requesting device&#39;s public key to decrypt the device ID. Certain embodiments will perform a lookup to ensure that this device type, or even device itself, is allowed connectivity using options such as a communications control list  2600 . If communications are authorized, the LDC  4500  will encrypt its LDC device ID with its private key and transmit that along with optional ordinal value for the communication policy selected and, as a further option, the encryption approach selected within the selected policy to encrypt the LDC ID. The requesting device will then optionally use those ordinal references and its LDC public key to decrypt the LDC ID to verify the correct LDC connection. At this point, in certain environments, the shared secret key will be used to transmit an optionally new ordinal value for long-running communications. Other embodiments will use the shared secret key to encrypt and decrypt the LDC ID, thereby saving a step. In these embodiments, the shared session secret is used as a way to launch long-running communication protection, through such options as modulation charts, rotating encryption keys and so forth. Then the shared session secret is, in some embodiments, discarded. Other embodiments will modify the shared session secret over time using distinct modulation sequences to enforce ongoing, out-of-band, challenge response efforts. 
     Unlike more traditional networks  4400 , IoT networks often require very long running sessions. Traditional security approaches were designed for short duration protection and, as such, are readily overcome in long-running communication environments. To this end, certain connected device-oriented embodiments leverage modulation charts, communication control lists  2600  and/or other options such as, but not limited to, precompiled modules, chip-based instructions or configuration files to generate long-running session protection. For the purposes of streamlining explanation, one set of embodiments might utilize an initiating device  202  and a target, or recipient, device  202 . To this end, the initiating device  202  may select, randomly or according to some set of rules or filters. In these embodiments, the initiating device may utilize encryption security key generation rules to create a variable number of encryption keys. These rules may control such options as the minimum and maximum number of keys to generate, the minimum and maximum size of each key and the algorithm(s) to use when creating these keys. 
     In certain embodiments, the generated keys will be sent to the target device  202  over an existing secure line of communication, such as the type described previously. At this point, each device  202  will know the ordinal position of each key in the set. Depending on the embodiment, either the initiating or recipient device  202  will then generate a random list of possible ordinal values. Some embodiments will enforce rules such that each encryption key can only appear a minimum and/or maximum number of times in the ordinal set of values, cannot be placed next to one another, have to appear next to one another and so forth. The key generation rules might also be broken down into subsets such that different keys of different minimum and maximum sizes are created. Rules for generating ordinal values might then include restrictions based on the size of keys and even the algorithm used to generate different keys. 
     Once the ordinal values are generated, the generating device  202  then securely transmits the ordinal set to the other device  202 . In these embodiments, the devices  202  can then use the ordinal values to determine what key to use for each packet as those packets are processed. This approach enables each packet to be protected with a unique key that can be different from other packets. Certain embodiments will use the ordinal values and/or the keys once and then re-generate both. Other embodiments will continuously use both the keys and ordinal values and may or may not re-generate both at regular or random intervals or in response to external factors ranging from throughput levels to retransmission rates to active user device application construct changes. Keys and ordinal value sets can be independently altered or altered in sync depending on the embodiment. The same or different key generation and ordinal value rules can be used to create one key/ordinal value set for all device communications, one for each type or communication (divided by protocol, destination, application and so forth) or some hybrid therein. 
     Key and ordinal value generation rules may be contained in an encryption set and there may be more than one encryption set depending on the embodiment. These sets can be changed according to a number of options as described in prior sections. Changing an encryption set may or may not cause an immediate change in keys and ordinal sets, depending on the embodiment, as certain embodiments might use the replaced encryption set&#39;s interval to determine when to switch keys and ordinal values to the new encryption set. 
     Once a given LDC  4500  and requesting device  202  are securely connected, and each endpoint is authenticated, simplified blockchain efforts can be supported. These communications can also be supported directly through two non-LDC devices  202  through the previously described LDC-based device ticketing approach. In certain embodiments, the device agent(s)  4520  of authenticated devices  202  can personalize encrypted delivery between devices through custom encrypt keying efforts. To this end, pre-existing values or even device tickets can be utilized as SALT values to customize encryption between any two devices In certain embodiments, the provisioning process, described in a later section, might provide a series of policies to a given device. Each policy may contain an optional encryption value called, for explanatory purposes, Blockchain Value A. In this example, an LDC might send a new policy update which will be encrypted using Blockchain Value A as its SALT value. The receiving device  202  can pull its Blockchain Value A from the current policy in order to decrypt the new policy. The new policy will then contain Blockchain Value B. To this end, a chain of updates can be securely transmitted over a secure, authenticated channel as shown in  FIG. 47 . 
     As a further example, in certain embodiments, the database can solicit the target device information, update type and a timestamp. The database then returns Blockchain A, as well as a new Blockchain B. The returned value is thereby inserted into the update (as Blockchain B) with the update type. In one embodiment, the returned value is inserted as metadata. Blockchain A might be a 32-bit UUID used as a “key” for encryption. In certain embodiments, the encryption is performed using a gzip (gz) filename or equivalent. After Blockchain B is returned, Blockchain A is then applied and the encrypted file is sent to the target device over independently secure, authenticated communications. The target device in turn uses Blockchain A to decrypt the update and obtain Blockchain B from the database. Finally, Blockchain B replaces Blockchain A as the new value for the update occurring on the system. Since the endpoints are known, the transaction is validated through the decryption process and the distributed ledger can be updated depending on the embodiment. 
     This process of distributed ledger updates is illustrated in  FIG. 47 . Here, the LDC  4500  comprises a domain database  4510  and at least one device agent  4520 . The local system also comprises at least a device A and a device B. Device A may send a transmission to device B as a main communication message, which triggers device A to send a communication log entry to the LDC  4500 . Once device B receives the transmission from device A, device B also sends a communication log to the LDC  4500 . The combined logs are the stored in a new ledge entry in the database  4510 .  FIG. 47  illustrates how the blockchain encryption/decryption can thereby become more distributed among the devices associated with the local system and LDC  4500 . From the devices, depending on the embodiment, to the LDCs  4500 , transaction entries can be rolled up or summarized to mitigate the amount of distributed ledger transaction data that flows in a system. Further, these entries can be encrypted using options such as a network key  4400 . The content of a transaction entry can vary depending on the embodiment but generally follow best practices found in more traditional blockchain ledger systems. 
     In one embodiment, the device agent  4520  implements one or more policies to direct workflow and prevent errors within the local system. The device agent policies are preferably applied throughout the entire local system, and may be updated or modified periodically. In addition, each module may comprise policies that are different from the device agent policies. Policies may include device policies, which may dictate internal configuration for each device in the local system. Device policies are preferably limited to a single policy per device, and may further comprise a communications control list (CCL)  2600 . Policies may also include communication policies, which are configured to protect longer running session protocols and communications. As opposed to device policies, communication policies may have multiple policies per device. 
     In embodiments, the CCL  2600  organizes communications by device type or by each unique device within a local system. The CCL  2600  may further contains the types of communications allowed (i.e., WiFi, Bluetooth, Ethernet, OTA and others). The CCL  2600  may optionally contain initiation rules in certain embodiments for each device, and may further dictate the specific encryption algorithm to apply in communications received or sent by a device. The CCL  2600  can also be configured to identify or provide the specific filters (described above) to apply, including by way of example but not limitation, the total amount of data allowed, the types or formats of data packets transmitted, timing, throughput, and other packet-level filters. In certain embodiments, the LDC  4500  maintains the registry of devices within the local system and may send updates of the CCL  2600  when a device is added or modified to maintain integrity. For example, the LDC registry contains the device public keys, device URIs and device types, which may be periodically provided to the CCL  2600  or as events occur (such as a change to a device). 
     Referring now to  FIG. 48 , a flow chart diagram is provided for demonstrating how encryption is applied during a particular session. In this exemplary embodiment, at least one communication policy is loaded and transmitted with the policy ID to each peer communicating during the session. If there is more than one set, then encryption chains are loaded, and if not an encryption set is loaded. If only one set, after the encryption set is loaded, encryption filters may be loaded, if any, and then applied to generate filtered packets. This process repeats until all packets have been filtered (i.e., the total number of packets has been reached). Alternatively, this process may repeat for a set time. In the event there is more than one set, the next step is to load the encryption chain, and then load the encryption set for that chain. If there is more than one encryption chain, the system may randomly load any one encryption chin and associated encryption set, and also transmit the loaded chain and chain ID to the peer. This may be repeated for each chain until completed, and may further include the steps of applying filters until all packets have been filtered. 
     The virtual management module  4530 , according to a preferred embodiment, comprises a visual user interface for visually displaying devices contained within the associated LDC database(s). This interface preferably facilitates direct interactions with each of the devices contained within the database, although in alternate embodiments the interface is configured to enable interactions only with devices of a certain type. For instance, the interface may apply filters for a user to select the type of device, type of communication, active versus inactive or known versus unknown devices, among other criteria. The interface also enables visualization from a very high level (i.e., at the level of the LDC  4500 ) as well as all lower domains contained within the local system. 
     Referring to  FIG. 49A , the device agent  4520  may be configured to comprise a virtual communications kernel  210 , which in turn provides device identity, authentication and secure communication. The virtual communications kernel  210  preferably resides at the kernel layer, outside of typical communication protection protocols for facilitating application during pre-boot loading protocols. In embodiments, the virtual communications kernel  210  loads immediately after BIOS  4910  operations occur. The virtual communications kernel  210  preferably performs a self-check diagnostic routine (preferably in a trust zone) before reverting to normal computing. This permits normal operating system boot operations to run, as shown in  FIG. 49A , without interruption. 
       FIG. 49B  provides an explanatory conceptual overview of a secure boot option that leverages the virtual communications kernel  210 . In this explanatory embodiment, a device  202  turns on and the core processes, such as the BIOS  4910 , boots up. Then the virtual communications kernel  210  turns on and switches the device  202  into trusted processing. Trusted processing is a well-known mode of operating that a person versed in the art will understand. While in trusted processing mode, the device agent may activate a Validation Module (VM). This VM obtains the device ID from the trust zone. A trust zone might be a part of a secure processor, a secure external storage option such as a USB key or another such location that is only accessible to properly registered, local, applications and/or processes. The VM will then, as will be described, re-generate the device ID and determine if the stored ID and generated ID match. If they do not match then an optional workflow will be instantiated that might alert other devices/LDCs, shut down the device, remove the device agent and so forth. If the IDs match then the trusted computing mode might be exited and updates sought after and processed prior to letting the rest of the device boot up. 
     The virtual communications kernel  210  may comprise one or more core modules, including an interface manager to interface with a host device or operating system, and to isolate other modules of the virtual communications kernel. Other modules may comprise a packet manager comprising the workflow engine (logic) to parse different types of packets and reconstruct those packets as necessary. Modules may also include a “cryption” manager to process encryption sets and/or filter packets requiring encryption. Alternatively or additionally, the “cryption” manager may also apply and manage encryption algorithms. The virtual communications kernel  210  may also comprise a key manager for creating and assigning encryption keys, and a device manager for coordinating transmission between modules. Finally, an update manager module may be provided for determining trusted versus normal computing transactions and for reading incoming updates from the local system clients or routed to target IoT devices (upstream or downstream). 
     In certain embodiments, modules are used to isolate types of processing—for example, packet processing, encryption/decryption, packet caching, device interactions and so forth—in order to minimize update impacts and to provider a path for subsequent functionality enhancements. As one example, a user agent might cache transmitted packets in order to handle re-transmission requests without forwarding those requests to an operating system/application. In these embodiments, the packets might be stored for the Time To Live (TTL) of each packet. In terms of updating functionality, an exemplary embodiment might wish to enable a new firewall management functionality. These new capabilities can be encapsulated into a new module and plugged into target user agents in those embodiments that support such a modular architecture. 
     Certain embodiments will take use this architecture to achieve a codeless user agent, wherein the agent&#39;s code is comprised only of workflow engines that, by themselves, do nothing. Only when workflow instructions are provided, through options such as a device policy, does this exemplary agent gain functionality. To this end, adding a new module can be reduced to adding a new workflow engine and then policies that integrate the new module and provide it with instruction on how to operate. By separating out the behavior of the device agent from the code running the workflow engines, changes in how the device agent  4520  functions can be quickly modified without and re-coding required. 
     These embodiments give rise to a visual device management option wherein all behaviors are contained in policies. These policies can be changed through a visual interface and then pushed to target device(s)  202  through the previously described authenticated blockchain system. The visual interface, depending on the embodiment, might show some visual representation of all managed devices along with options to directly change how an individual device, pre-defined group or dynamically defined group of devices behaves. Examples include, but are not limited to, how devices initiate communications, what encryption is used between device, the types and number of encryption keys or the creation and revocation of higher-level organizational keys. 
     In order to visually manage a potentially large number of devices, an indirect management approach has to be leveraged in certain environments. In most modern management system, such as Active Directory or Open LDAP, direct communications have to be present at all times in order for devices to be centrally-managed. This approach necessarily fails at large number of connected devices due to the large overhead of these connections and due to the intermittent connectivity found in many large IoT deployments. Instead, an indirect, reporting-based system needs to be provided in these embodiments that relies on local system enforcement of policies along with distributed ledger and alert-based issue reporting.  FIGS. 60A through 60E  describe how local systems enforce policy updates and what occurs when policy updates fail in certain embodiments. In addition to the alerts shown in these workflows, distributed ledger entries can be leveraged in different embodiments to track and visually inspect policy deployment successes and failures. 
     By basing management on trusted local system enforcement, central virtual management applications can observe the status and protection in remote systems even with intermittent connectivity and shown in  FIG. 60F . Certain embodiments can reduce the overhead by rolling up alerts and transactions thus enabling an out-of-band management system. This system, as shown in  FIG. 60G , enables embodiments to provide complete communications protection without operating on the protected devices directly and without needing to intercept and read the communications being secured. 
     The virtual communications kernel  210  may also comprise one or more data modules, such as an event manager module for applying policies or to translate device events into an appropriate format for processing. Other data modules may include a log manager for capturing all communications and transactions into a unified format, or a health manager for recording and/or reporting processor speed, temperature, power usage, memory, etc. in a standard format. The virtual communications kernel  210  may also comprise an analytics manager, which obtains data from the other data modules and processes that data according to one or more rules established by the user. Various remediation modules may also be provided, including a workflow manager to control the processing of workflows across other modules, or an alert manager to communicate alerts, such as failures. Other modules may include a process manager for stopping or redirecting data for a particular process, and a firewall manager for stopping or redirecting data for a particular port. 
       FIG. 50  depicts the structure of an exemplary data packet, as well as the manner in which a packet may be processed by a device agent  4520 , according to one embodiment. As shown in  FIG. 50 , and according to an exemplary embodiment, the packet headers  5010  (Ethernet and other network layer headers) are initially stripped away (step 1) from the packet. Next, the core transport layer  5020  data is extracted (step 2). This permits the core datagram to be encrypted (step 2), as described in greater detail below. Next, the core transport layer  5020  is reconstructed into the packet (step 3), and the network and Ethernet headers are added back into the packet (step 4). At this point, standard fields (such as length and checksum) may be updated as needed. 
     Referring now to  FIGS. 51-63 , a number of workflow or flowchart diagrams are shown to further illustrate certain aspects of the present disclosure. Referring to  FIG. 51A , a specific workflow associated with a new customer acquisition is shown, which in a preferred embodiment comprises a number of discrete steps, some of which may be repeated depending on the particular needs of the system. In one step, a new customer may submit a new customer request, which preferably is routed through a customer cloud associated with the system and eventually to, for example, a public extranet. In another step, an alert is generated and routed to an administrator, which may result in the creation of a new agreement, depending on the nature of the customer, or may result in a new application for the customer. In another step, a unique login is created for the new customer and access to the system is granted. In another step, the system is provisioned and allowable device types are specified. 
     Depending on the type of customer, agreement and so forth, a preliminary agent might be provided on devices during a manufacturing or provisioning process. This initial device agent, at time referred to as a thin agent, has a small set of functions devoted to installing the latest version of the full device agent when the device  202  is fully activated. This approach might be used when creating a large number of device(s)  202  that might take months, or even years, to sell to customers. As such any full implementation of the device agent when the device  202  was first created would be obsolete when the device is later activated. Leveraging an initial thin agent overcomes this limitation. 
       FIG. 51B  provides a conceptual overview of such a system wherein a provisioning system obtains a series of thin agent licenses, in this exemplary embodiment, in return for providing a series of public keys (referred to here as Run Public Key(s)) whose private key pairs will be nested within devices during provisioning. The provisioning system, in these embodiments, also provides a unique provisioning ID and optional device metadata such as the type of device, operating system, name and so forth. This information is stored within the main device registry and then, as described in the activation workflows, provided to a possible disparate customer device registry during later device activation. 
     Other embodiments might leverage a thin agent during a largescale deployment in order to load a default installer on each device. In certain embodiments, this thin agent can then request a full agent from a local LDC or other defined deployment location. Using this approach minimizes network traffic, enables any localization customization and can increase overall deployment by offloading the main work in a distributed manner. 
     During start up and provisioning stages of a new system, the thin device agent may also complete a number of other functions, including creating a unique device key pair for each device. The thin agent preferably creates a device ID and a hash of the device ID, which are then stored in, for example, a trust zone. The device ID may comprise specific steps or processes in the particular device ID string, which may be encrypted using the unique device key described above. According to embodiments, the system can authenticate a device by obtaining a device key, decrypting a device ID string, recreating the device ID, then matching the values of the device ID stored in the trusted zone (which itself may be encrypted/decrypted) to ensure integrity among devices. Any failure during this process may cause a workflow error process to be initiated. Specific error protocols are described in greater detail below in connection with  FIGS. 55-56 . 
     In certain embodiments, the generation of the device ID is a critical foundational element upon which many other operations rely. By continuously self-authenticating the device ID, a local device agent knows the device upon which it operates and this feature significantly reduces authentication processes and described previously. To this end, the device ID is a dynamic process that, in these embodiments, can be modified at any time to provide additional layers of protection. Some embodiments might utilize, but are not limited to, accessible provisioning, manufacturing, hardware and even application registry identifiers. Embodiments might include randomly-generated values, optionally stored in a trust zone, in order to achieve security requirements. Any aspect of a device that is not subject to random changes can be leverages including, as one example, a hash of the device agent&#39;s libraries. The only requirement is that a relatable device ID can be re-generated at a second time period in order for validation to occur. In certain embodiments, the device ID has to be the exact same for matching purposes, whereas others might use a time-series to achieve correlative matching. Even others might use known, of expected, changes within a device to calculate the new device ID based on those changes and the original device ID. 
     Referring now in detail to  FIGS. 52A-C , various processes and sub-processes relating to initialization and device activation may be described. Once the unique device key pair has been created and stored in the trusted zone, a cloud device ID may be generated, preferably along with a hash of the cloud device ID, which in turn may be stored in the trusted zone. Next, the system may be queried to obtain the location and device name from the LDC. Alternatively, the system may be queried to determine if the device in an LDC, or if there is a parent LDC associated therewith. Next, the device key may be encrypted, along with a public key, and then transmitted to the LDC. Encrypted information transmitted to the LDC may further comprise: production run date and ID; production public key information; device type name; device location name; manufacturer ID; device name; device public key (and hash ID); and other information. The encrypted transmission to the LDC may further embed cloud domain information, preferably as metadata. Then, the LDC preferably passes the transmission to the Main Domain Controller (MDC). This pass-through may further comprise encrypting the cloud device ID with the LDC&#39;s public key and/or hash ID, and may embed this information as metadata. Additionally, the system may replace the cloud domain of a particular device with the matching MDC IP if an LDC has been identified. Then the MDC sends the encryption package to the LDC. In this transmission, the endpoint public key is preferably assigned. Next, the LDC receives and forwards the encryption package to the endpoint. The LDC also stores the device public key assigned in the prior step. Next, the endpoint may use the device private key and hash to decrypt the Blockchain A value, as referenced above in connection with paragraphs [00253]-[00259]. Then the Blockchain A value may be used to unzip an encrypted installation routine, or utilize the device private key and hash to decrypt the installation routine. Once unzipped/decrypted, the endpoint may download and install the security package. This step of installation may cause the thin device agent to be removed or inactivated. 
     As shown in  FIG. 52A , any errors are reported to the LDC, which in turn determines whether a re-install or alert is necessary based on the error(s) reported. If necessary, certain steps may be repeated to ensure re-installation is requested and achieved. After these steps are completed, device initiation (as described in more detail in connection with  FIGS. 56A-D ) occurs. 
     Referring now to  FIG. 52B , a flow chart diagram outlines some of the steps of updating a module, according to embodiments of the present disclosure. Certain of the steps in  FIG. 52B  are optional, including those designated as such in the Figure. In a preferred embodiment, all type identifiers (whether module or policy identifiers) are encrypted using the device key pair and added to the messaging as metadata. The updates, once completed, are stored in the LDC database. 
     Referring now to  FIG. 52C , a workflow diagram is shown for establishing communications between a user and a device on the local system. Here, the LDC preferably establishes an initial connection with the user, whereby a communication is sent to the user via the cloud and includes the list of devices stored in the LDC database. Next, the user sends a command through the cloud to the LDC, preferably with authorizations for one or more devices listed. Next, the LDC sends a command authorizing the device(s) according to the user&#39;s command sent to the LDC. Thereafter, in-band communications between the device and the controller are established. 
     Referring now to  FIG. 53 , a workflow diagram relating to Blockchain deployment is shown. In a preferred embodiment, after each module update has occurred (as described in connection with  FIG. 52B ), a transmission is sent to the LDC  4500  that comprises encrypted information, including associated metadata. Alternatively, the transmission is sent to another domain controller before the transmission is received by the LDC  4500 , as shown in  FIG. 53 . Regardless, the LDC forwards the transmission to the endpoint. During these transmissions, the Blockchain security protocol (as described above) decrypts the outer layer of the transmission. If local data is found to be present, that data is processed and the transaction recorded in the local Blockchain registry. Metadata may also be recorded for further routing other data, such as any relevant module data. After the transmission is received by the endpoint, alerts may be generated, particularly if unknown data is received. The alert may be sent to the LDC  4500 , other domain controller or to the cloud application(s). 
     Referring to  FIG. 54 , an exemplary workflow relating to Blockchain processing is shown. Here, a device may request a new policy or module and transmit that request to the LDC  4500 . This request may trigger an optional step of sending an update from the cloud to the device, which may include a policy/module update. Alternatively, the LDC  4500  may send a Blockchain package to the lower level device with the requested policy or module. In another embodiment, the LDC  4500  acquires the policy/module update from the MDC. Regardless, all databases are securely replicated and the transmissions recorded in the LDC database. 
     Still referring to  FIG. 54 , the Blockchain security protocols described above may be followed, whereby the Blockchain package received by the lower level device is sent through the encryption process and ultimately replaced with each new policy/module associated with the type of update requested. Next, the encryption/decryption process may trigger a reporting message to the LDC  4500 . If the message decryption fails, an error message may be sent to the LDC  4500  and recorded in the local system database. 
     Referring now to  FIG. 55 , an exemplary workflow is shown for reacting to identification of an invalid device on the local system. If an error message is received, or during boot operations the system receives an indication there is invalid hardware, a message is transmitted to the LDC  4500 . The transmission may be Blockchain encrypted using a provisioning ID. Once received by the LDC  4500 , the LDC  4500  may in turn transmit that message to the MDC and/or to the cloud. If transmitted to the cloud, authorized hardware changes and synchronization authorization may be supplied back to the LDC  4500  and, if authorized, a new dataset and Blockchain-encrypted device ID may be delivered back to the trusted zone. In the event the invalid device ID is not authorized, the LDC/MDC may send a command to shut down or other information to troubleshoot the error. Once received, the transmission from the LDC/MDC is Blockchain-decrypted and the invalid device is either updated or shut down, depending on the authorization received. 
     Referring to  FIGS. 56A-56D , exemplary workflow diagrams relating to device initiation are shown. In  FIG. 56A  an exemplary workflow for initiating a device where the controller is out of date is shown. Here, the workflow preferably comprises a session initialization request and authorization sequence, as shown in steps 1-3 in  FIG. 56A . If during this initialization an out of date massage is received, a transmission with the current controller version and policy update request is generated and delivered to the LDC/MDC. The request may also be sent to the cloud, where the update for the out of date controller is encrypted and transmitted back to the LDC/MDC. An updated set and associated metadata relating to this update are preferably passed through the LDC  4500  and to the endpoint, where the Blockchain is decrypted and the controller update is loaded. An optional error message may be sent if the message decryption fails. 
     Referring now to  FIG. 56B , an exemplary workflow diagram depicts a similar sequence in the event an IoT device is out of date. As shown in  FIG. 56B , the transmission from the cloud may also comprise a message identifying any known exploited or no longer viable device versions to the MDC/LDC, and may update the database with the information. Referring to  FIG. 56C , a workflow diagram shows the steps involved in the event the IoT device is determined to be out of date, and the cloud is at least temporarily disconnected. In these circumstances, the LDC/MDC messages the affected device and stores the information relating to the error in the local system database(s). 
     Referring now to  FIG. 56D , an initiation workflow is shown when a IoT device checks in as normal. Here, a hardware and device ID check is performed (see following paragraph for further information) and the device retrieves the device private key and loads the client modules into the untrusted zone. Next, a session initialization request is transmitted to the LDC  4500 . The LDC  4500  then obtains Blockchain encryption value and sends a transmission back to the device with the ID and hash ID (version control). At this point, the device preferably generates its own symmetric private key, such that all communications beyond this initial stage are encrypted moving forward. Next, the device compares the transmission from the LDC  4500  with the CCL  2600  to see if there is a match in the version. If yes, the device transmits a message to the LDC  4500  with the version control hash and the device ID, which is then validated by the LDC  4500 . Next, the LDC  4500  transmits the device ID and a communication policy to the device, which in turn are validated by the device. Then the device can transmit an ordinal key string, based on the communication policy, which causes the LDC  4500  to transmit the session keys based on the controlling communication policy. In this manner, encrypted session-based communications may commence. 
     The system preferably comprises a device policy for locating and identifying IoT devices within the local system. The device policy contains a device type ID for each device, and may further comprise a hardware ID. Thus, the device policy maintains the list of possible hardware components along with paths for obtaining identifiers associated with each component. By paths, this disclosure is intended to refer both to physical paths as well as dynamic data or function calls to make local BIOS connection. 
     The device policy also determines the minimum number of hardware to collect information from, and may also comprise a maximum. At initialization, the device policy may randomly select and assign hardware IDs within the maximum range. The position of the selected hardware component(s) is stored within the hardware ID string. In this manner, the device policy established a unique ID for each device component in the local system. 
     Once located, an ID gen module creates an actual device ID and the device ID string. The module may randomly select an ID for the ID string, or may generate a random alphanumeric string. This is repeated until each device is used at least one time. Preferably, the hardware ID string contains the start and stop positions at the end of this process in the event the process needs to be replicated. Then the device IDs are stored in the local trusted zone, and preferably a hash ID is also generated and transmitted to the LDC  4500  using the Blockchain encryption described above. If a hash ID is generated, the rules for hashing may be stored and retrieved from the device policy or other CCLs  2600  at the device level. 
     Referring now to  FIGS. 57A-57B , workflow diagrams for device initialization and provisioning are shown. In  FIG. 57A , the IoT device may transmit the address and out of band management port information to the LDC  4500 , which commences a two stage symmetrical key generation process shown in steps 4-6. If this exchange is successful, a connection is established with the cloud and the device list is sent from the LDC  4500  to the user (via the cloud). In  FIG. 57B , provisioning and initialization steps are shown from the user&#39;s perspective. Here, the thin device agent may be installed and used to generate a key pair and inquire about device location, name and other information. After passing the request to the cloud, the public key is transmitted to the device (encrypted) and full installation is allowed to proceed. The process may also involve a request for updates and to make local changes, as depicted in steps 10-13. 
     Referring to  FIG. 58 , the system and methods disclosed herein further enable peer-based communications over a local network. Initiation of peer-based communications is shown in  FIG. 58 , wherein the IoT device may submit a dynamic request for an ID (encrypted with the current device key) and transmit the request to the LDC  4500 . The LDC  4500  then validates the device and the request, verifies a target URI and submits the session key with the encrypted device key. This may further comprise a Kerebos-based session key encrypted with the peer device&#39;s device key. The encrypted values are verified and authorization is obtained. Once alerted of this status, the current device transmits a version control has and device ID to the peer device and, if authorized by the LDC  4500 , a request ID and session key is transmitted to the peer device. Next, the current device transmits an ordinal key string based on the communication policy to the peer device, and the peer device transmits session keys to the current device based on the communication policy. From this point, peer-to-peer device communication is allowed as shown in  FIG. 58 . 
     Referring now to  FIG. 59 , a workflow diagram depicts a process for making a policy change. In this diagram, the system permits security changes and has communications enabled. Initially, a command is sent from the user through the cloud to the controller. The command and policy to be changed is the transmitted to the device. The command is confirmed by the device, and then the controller reprocesses the symmetric key as described above. The device may place all packet handling into a holding loop while the new policy change is updated. Next, the command and re-key processing is confirmed by the device, and once the controller confirms that no more packets are being received from the IoT device (i.e., it is safe to enact the policy change), the controller switches to the new encryption. The holding loop, if enabled, is dissolved and the current device sends a command message confirming the policy change. The new encryption policy is then stored in the controller, and a message may be sent back to the user confirming the connection list. 
     In  FIGS. 60A-E , various policy enforcement workflow diagrams are shown. These policy enforcement workflows include bidirectional communications, where all conditions are normal ( FIG. 60A ), bidirectional communications, dataset update ( FIG. 60B ), bidirectional communications, majority matches but not local ( FIG. 60C ), bidirectional communications, most match local but one if wrong ( FIG. 60D ), and unidirectional communications, bad hash detected ( FIG. 60E ). 
     Referring now to  FIG. 61 , a diagram showing CCL  2600  generation steps is provided. If the local device has been successfully initiated, and the user authenticated, the CCL  2600  may be generated by requesting the CCL  2600  from the LDC  4500 . The LDC  4500  then uses a user token and the device ID from the local device to retrieve the correct CCL  2600  based on the device ID. Net, the CCL  2600  is sent from the LDC  4500  to the local device. In addition, the CCL  2600  may be automatically updated when other device peers are added to the system, such as peer device A and peer device B shown in  FIG. 61 . 
     Referring now to  FIG. 62 , it may be necessary to periodically change LDCs  4500 . In this scenario, the current LDC and new LDC operate simultaneously to facilitate the exchange. The device can send a request to transfer authorization to the new LDC, which is received by the current LDC. The current LDC then transmits a request to the MDC, and the MDC may pass that authorization request to the cloud. Confirmation of authorization is sent to the device with the new LDC public key, preferably encrypted using the device public key (Blockchain-encrypted for the specific device). The device then decrypts the new LDC public key and verifies the new LDC signature. The device then sends a confirmation of transfer of control to the new LDC. 
     Referring to  FIG. 63 , a workflow diagram for providing device updates according to embodiments is shown. Here, the cloud sends a heartbeat check signal to the bit bucket for the LDC  4500 . Any endpoint updates or changes may be provided at this time. Then the cloud sends a client update to the LDC  4500 , which is preferably Blockchain-encrypted for each device to receive an update. The update may comprise a new Blockchain, which can be added to the archive by using the old Blockchain as the password when creating the archive. The LDC  4500  then transmits the Blockchain-encrypted updates to each device. The devices that receive the update then decrypt the package using the currently-stored Blockchain and run the update. Then the device stores the new Blockchain issued by the cloud. 
     According to certain embodiments, methods of employing and managing the systems described above are further disclosed. For instance, a method of installing a configuring a device, according to one embodiment, involves the steps of: (1) initiating an image/installer upload request; (2) determining whether there is more than one device type present in the system; (3) selecting the device type; (4) determining if there is more than one storage option present in the system; (5) selecting the storage option; (6) entering the title, description, version number and optional hash; (7) uploading image/installer; (8) determining if there is a hash provided, and whether hash matches image; (9) performing differential analysis; (10) storing metadata; (11) generating a differential hash for each device type; (12) determining whether multiple differentials are present; (13) combining a quantity of differentials into a major update; and (14) storing the data in the device repository. 
     According to another embodiment, a method for boot operations is disclosed, comprising the steps of: (1) powering the devices on; (2) performing a core process boot; (3) initializing and activating trusted processing; (4) applying policy(ies) to build device IDs; (5) retrieving current device ID from trusted zone; (6) determining if devices match; (7) running an invalid device ID workflow; (8) using a private key to decrypt and load desired modules; (9) shutting down validation modules and exiting trusted computing zone (10) sending a unicast call to LDC  4500  consistent with device initiation workflows; (11) determining whether there are new images/modules; (12) allowing boot load process to continue; (13) re-entering trusted computing; (14) blockchain decrypting modules and images; (15) loading modules and images into untrusted computing space; and (16) determining whether updates have been made. 
     In referring to  FIG. 64 , the topology of LDCs  4500  can be described for various embodiments. As shown, certain embodiments may optional nested LDCs to create a hierarchical organization that provides a central, cross-customer, cloud controller at the top and then a series of LDCs below. In these logical embodiments, a customer may have one or more LDCs that have final authority over all, or part of, an enterprise. In this diagram, these LDCs are referred to as main customer controllers (MDCs). Next to the main cloud, a conceptual policy and new or update module are shown and are placed in a blockchain-protected deployment. As shown, these deployments are broken down across LDCs such that each LDC and, eventually, device obtains a custom-protected blockchain-secure deployment. 
     The concept of locally-enforced regions within the overall protected enterprise is further reflected in  FIG. 65 . In this example, a device agent  4520  has detected an issue and has set an alert. The subsystem within the first red box may optionally run workflow in an attempt to remediate the issue. In certain embodiments, a failure to overcome the issue might raise the problem to the next, larger, subsystem. This process can optionally repeat until the main cloud obtain the issue and a solution is generated and sent back to the device. 
     In terms of determining solutions, certain embodiments may utilize a system similar to the one provided in  FIG. 66 . In these embodiments, device health, communication logs and/or device events are collected. Certain embodiments take advantage of the dynamic nature of policies to provide a mapping feature that enables a device agent to map device-centric logs, events and health metrics into standardized formats. Leveraging these mappings for example, device agents  4520  can send a file write fault independent of the operating system that originally generated the event. By removing the complexity, or cleaning, the data at the source of collection, anomaly detection in the threat analytics engine is greatly simplified. 
     The threat analytics engine is both an anomaly detection system and an augmented machine learning system. By removing the noise of various devices, anomaly detection can be streamlined with normalized values across vendors, thereby easing the burden of determining actual issues. To this end, each customer threat engine is tuned by customer administrative responses. Thus, over time, customer input can modify acceptable and unacceptable ranges for various types of events, health metrics and/or communication logs. 
     In terms of a remediation paradigm, certain embodiments provide a partially automated remediation system wherein device-centric suggestions are provided based on prior responses and modeled to overcome a similar issue. For example, if one type of camera is exposed to an internal malware attack that opens a pirated video feed and the manual response was to block the ports of the pirate stream, then a similar attack on another type of camera would elicit the same suggested response. Certain embodiments enable admins to allow for full automation for any type of issue, for example shutting down overheating devices, and force manual intervention for other issues. Responses do not have to be simple and, in certain embodiments, the steps admins take to overcome an issue can be recorded in complex BPEL-like workflows. 
     These workflows can be transmitted down to remediation workflows residing at multiple levels within the managed system. Therefore, a complex response to an intrusion, as one example, can be optionally deployed to possible target devices. This feature, in these embodiments enables a powerful protective feature at the point of attack. Workflows may control what ports are opened closed, if devices are turned off, what connections are allowed, and even what applications are turned on or off. 
     This ability to modify the overall behavior of devices has potential applications to operational technology (OT) in certain embodiments. As shown in  FIGS. 67A-D , the same devices can support multiple configurations depending on the policies provided to the user agent.  FIG. 67A  provides a configuration wherein smart lights are controlled in a fine grain manner and can be turned on or off, partially supplied with electricity and so forth as part of a power management configuration.  FIG. 67B  shows the same devices but in a configuration wherein a series of sensors, such as those deployed remotely in oil pipes, are running. In this configuration, a local policy contains a remediation workflow that shuts down a bad sensor and brings up a backup sensor for zero downtime maintenance.  FIG. 67C  provides a common configuration wherein a central hub is used as the main connector between disparate software systems. In this role, the central hub has to translate and merge communications from these isolated software systems. The final example, shown in  FIG. 67D , provides the ability to transmit data through insecure environments. In this case, the same central hub is now being utilized in a healthcare setting with sensitive data being transmitted from one device through the central hub to a data repository. The device agents  4520  can lock down this transport of data without impacting any other functions, acting in the role of a restricted super peer, to support compliance requirements such as HIPAA or GDPR. 
     In order for the virtual communication kernel  210  to effectively secure a device throughout that device&#39;s lifecycle, certain embodiments require it to initialize prior to the host system being booted up in a manner that cannot be exploited. Given the lack of operating system dependencies, the virtual communications kernel  210  can be loaded directly out of a BIOS (such as through an interrupt  32 ). However, if the virtual communications kernel  210  is moved one level down then it becomes even more secure. 
     The BIOS in modern devices is used to enable an interface between any number of physical components and the host system. The issue with modern BIOS systems is a lack of security in that any hardware component with access can register itself with a given BIOS. In fact, it is this lack of security that enables the wide range of BIOS exploits currently plaguing devices irrespective of the host system. 
     The challenge with BIOS-level security is threefold. The first challenge is determining what physical components are authorized to join a given system—otherwise referred to as an authenticated configuration. The second challenge is maintaining secure hardware information without adversely affecting upper level processes. One of the larger challenges in modern systems is properly identifying a device while overcoming spoofing attempts. The last challenge is allowing for access to update secure systems while preventing unauthorized intrusions. 
     Given the virtual communications kernel&#39;s  210  ability to establish its own secure communication channels, the option for a secure BIOS becomes a reality. In this instance, a device being provisioned initially installs the virtual communications kernel  210  BIOS. The virtual communications kernel  210  BIOS then inspects the hardware components and determines the communications equipment for an active connection which it assumes is not safe. 
     The virtual communications kernel  210  BIOS then obtains the configuration information from a remote configuration data store using an embedded policy. This discovery process between the configuration data store and the new device occurs as described previously. Once secure communications are established, the virtual communications kernel  210  BIOS obtains the configuration profile from the remote store, for example an LDC  4500  or according to previously explained provisioning/initialization workflows, which includes the provisioning ID and box as well as the allowed hardware components for that device. 
     Then the virtual communications kernel  210  BIOS iterates through the discovered hardware components and only registers those components authorized in the configuration profile. The profile itself may enable more components than presently discovered and it might open general options, such as USB or Bluetooth connectivity. The profile, therefore, defines the superset of all possible components allowed to interact with a given host system. Further, active user device and user device application constructs can be enforced at this level to control what hardware is available to different access attempts. 
     During the registration process, the virtual communications kernel  210  BIOS preferably creates a registration table that is stored, in an encrypted format, is a specially-provisioned section of the device&#39;s physical memory—be it ROM or RAM—which is closed off from the rest of the host system. These special sections are commonly referred to as shielded locations and are found in Trusted Platform (TP) implementations. Since the virtual communications kernel  210  BIOS sits in between the host system and the hardware components, it can define the usable sections for each hardware component. This process enables a hyper-secure subsystem into which the virtual communications kernel  210  BIOS can store actual hardware identifiers and map those to encrypted hardware identifiers that are published to the host system. 
     This latter feature enables a secure ability to authenticate provisioning identifiers using hardware component identifiers in a manner not accessible to the rest of the host system. Thus two device agents  4520  can securely exchange MAC-level encrypted hardware identifiers and provisioning identifiers and authenticate in one step without releasing any information to any upper level system that would enable spoofing, eavesdropping or any other currently known exploit vector. 
     As explained earlier, the processing instructions for a given provisioning box can be secured using the hardware identifiers as part of the encryption process. By removing the actual identifiers from the upper level processes, a virtual communications kernel  210  BIOS implementation provides another layer of protection against tampering with these boxes. Up to this point, the virtual communications kernel  210  BIOS implementation has provided a method for enforcing hardware component registration and for detecting corrupt profiles. Given the peer-based enforcement, however, the BIOS can go one step further as shown in  FIG. 69 . Each time a protected device boots up in these embodiments, the virtual communications kernel  210  is able to securely check its known good configuration against the current hardware configuration to see if the device has been corrupted. Once two devices have established secure communications, each device can exchange its known good configuration profile with the other device. As explained previously, these configuration profiles would be stored in a highly-secure section of physical memory (not accessible to upper level processes) in an encrypted manner. 
     One thing to note is that the lower the system resources (e.g. less memory), in general, the smaller the number of connected devices. Thus a sensor might only ever connect to one hub whereas a cloud server—with significantly more resources—could connect to a multitude of devices. In addition, many configuration profiles would be similar, if not exactly the same. To this end, the virtual communications kernel  210  BIOS would parse incoming configurations into its own internal representation. This would enable a given virtual communications kernel  210  BIOS to store deltas between profiles instead of whole profiles for each device. 
     Once exchanged, device discovery would be initiated in one of two manners. First a local virtual communications kernel  210  BIOS, during boot, would recognize that it was corrupt. In addition, optionally using ARP packets, each BIOS would use a heartbeat message to ensure its proper configuration with other connected secure and authenticated devices. This heartbeat is intended to ensure that all devices in a given connected system are not corrupt. A heartbeat can be sent on a regular/irregular interval or, if not received within a general timeframe, requested by a remote, authenticated device. 
     If corruption is detected, then the corrupted device would request its configuration policies from all connected devices. The corrupted device would take the most commonly returned policy, if there are differences, and use that policy to disable any unauthorized hardware components—thus returning to its valid state. Once the device has been corrected, that device would reinitialize its communications with all connected devices. 
     The last main BIOS-related challenge focuses on controlled access to restricted resources. To better understand how these embodiments addresses this last concern, an explanation of Trusted Platforms and UEFI is required. Unified Extensible Firmware Interface (UEFI) is the modern replacement for older BIOS implementations. UEFI leverages a Trusted Platform Module (TPM) to ensure that the low level system is properly identified and secured. Instead of provisioning identifiers, a TPM typically utilizes a private CA certificate to authenticate these low-level attributes during provisioning. In these implementations, the validation of the identifier is external which brings the self-peer model presented herein. 
     These new embodiments, in contrast, not only require the equivalent of a certificate, they further require an internal ability to validate that certificate equivalent. This effort to internalize validation, combined with encrypted processing instructions based on obfuscated hardware identifiers makes spoofing much more challenging. 
     At a high level, UEFI leverages a TPM in order to verify that the local system is valid. It then uses this protected information to carry on secure BIOS-related boot and discovery processes required to load a host system. 
     Based on the foregoing, these embodiments may further extend the inherent certificate process into a self-regulated system, as demonstrated through the conceptual diagram presented in  FIG. 70 . In this case, instead of the TPM directly accessing an external certificate possibly stored in a shielded location, the TPM is accessing the provisioning ID that has been authorized using the provisioning box—both stored in the aforementioned encrypted manner in a shielded location. By enabling this layer, these embodiments remove the external dependency to support peer-based verification and auto-correction. 
     In reviewing the exploits found in UEFI, it is apparent that, while secure, UEFI is still reliant on a lack of access as protection against intrusion. In each of the exploits, attackers were able to gain access and negatively impact a UEFI system simply by connecting and looking for vulnerabilities. By leveraging communication control policies to manage what devices can communicate with whom as well as the direction, protocol, size and duration of those communications, these embodiments can extend this concept into a communications controller that closes the gap for UEFI exploits. 
     In almost all cases, a BIOS should never allow incoming requests after an initial provisioning effort. Of course, adding new hardware components is a standard exception but, in those cases, isolating the hardware identification/configuration validation process from the rest of the BIOS effectively removes that attack vector. 
     In the case of the virtual communications kernel  210 , flashing is never a required option as all updateable components are able to be changed in isolation. For example, in  FIG. 70 , the original RSA Engine, SHA-1 hashing algorithm and RNG pseudorandom generator have been replaced with more generic options to reflect the ability to update in place. By enforcing a compartmentalized updating process, these embodiments significantly increases the challenge in overwhelming and comprising a secure BIOS system. 
     As the complexity of manufacturing of more sophisticated devices, sometimes referred to as smart devices  7000 , increases, device  7001  providers increasingly rely on component  7000  manufacturers to support the burden of creating parts for their overall smart devices  7001 . These smart devices  7000  can range, but are not limited to, smart appliances, automation devices for the home, office, production, robotics and so forth. Over time, certain component  7000  manufacturers have obtained special certifications denoting the security of their components  7000 . While the actual components  7000  are generally the same in terms of quality across certified and non-certified component  7000  manufacturers, certified manufacturers often charge significantly more for their components  7000 . Device  7001  providers, despite a strong desire to lower component  7000  prices, are typically forced to purchase the higher-price options for a number of reasons from business obligations to regulations to other concerns. Over time, these certified components  7000  have not proven to be any more effective at protecting smart devices  7001  from any form of cybersecurity issue. Device  7001  providers are therefore caught in a disadvantageous scenario wherein they are purchasing higher-priced, certified, components  7000  and still not providing any more secure devices  7001 . 
     Certain embodiments of the current invention address these challenges, as shown in  FIGS. 71 and 72 , by anticipating unreliable components  7000  at the level of a smart device  7001 . In  FIG. 71 , several components are shown in a configuration wherein the virtual communications kernel  210  is implemented in any of the manners described previously outside of a BIOS. In these instances, hardware components  7000  are able to communicate with one another but they are not able to directly communicate with the outside world unless authorized by the virtual communications kernel  210 . In these embodiments, device  7001  providers can ascribe rules to each hardware component  7000  that severely restricts external communications accordingly to the methods described previously. Without access to the external world, hardware components  7000  cannot be triggered remotely, send unauthorized data or, in most other manners, be utilized in a malicious manner regardless of the code provided in each hardware component  7000 . Further, leveraging the updateable manner of the user agents, the rules for locking down these components  7000  can be upgraded over time to provide ongoing security. 
       FIG. 72  provides an enhancement in certain embodiments wherein the virtual communication kernel  210  is implemented as a protected BIOS which was presented in the previous section. In these embodiments, all hardware components  7000  communicate through the virtual communications kernel  210 . This additional control prevents time bomb-based attacks wherein code embedded in a given hardware component  7000  triggers based on some internal event, examples include time period, device health metrics, data flow and so forth, and that code attempts to attack and/or overcome other components. Another layer of rules can be applied to further control component  7000  to component  7000  interactions in order to prevent these attacks. Also, by placing the virtual communications layer in between all components  7000 , component health metrics can be monitored and component failure options are generated, depending on the embodiment. Therefore if a component  7000  starts to experience issues, due to possible events such as malicious intent, malfunction or lifetime issues, amongst other factors or some combination therein, the user agent containing the virtual communication kernel  210  can both failover to a backup component and, depending on the embodiment, run a remediation workflow that sends out alerts. These latter embodiments are very advantageous both for expensive equipment such as a CAT scanner and for leveraging lower quality, cheaper, components in, as an example, a grid computing paradigm. 
     The above discussion is meant to be illustrative of the principles and various embodiments of the present invention. Numerous variations and modifications will become apparent to those skilled in the art once the above disclosure is fully appreciated. It is intended that the following claims be interpreted to embrace all such variations and modifications.