Patent ID: 12238204

Corresponding numerals and symbols in the different figures generally refer to corresponding parts unless otherwise indicated. The figures are drawn to clearly illustrate the relevant aspects of the embodiments and are not necessarily drawn to scale.

DETAILED DESCRIPTION

Computer network security is vital to its basic functionality. If traffic on a network may be compromised or observed by a third party, sensitive information may be revealed and become impossible to protect. This is particularly problematic in settings where sensitive and confidential information may be transmitted over infrastructure that is not always under the control of the transmitting corporation or organization.

End-to-end encryption of network traffic is used to protect information on such networks and prevent third parties from obtaining the content of the transmitted information. Example approaches to facilitate end-to-end network encryption and protect information transmitted over the network, include common keying among hosts, and unique keying for every pair of communicating hosts.

Under the common keying approach, all hosts are configured with a known pre-shared cryptographic key, which is used to facilitate encryption and decryption of traffic between hosts on the network. The common keying approach is a much less complex approach to end-to-end encryption compared to the unique keying approach. However, common keying is at risk of the entire network becoming compromised in the event that the common cryptographic key is exposed. Because all hosts in the network share the same cryptographic key under the common keying approach, if the key is exposed by any number of means, including external cryptological attack, leak via an insider threat, or because any one of the hosts have been compromised by an unauthorized person, all traffic on the network may be captured, viewed, recorded or otherwise compromised by an unauthorized third party.

The unique keying approach prevents the occurrence of such widespread compromise events upon the exposure of any one cryptographic key in the network that are possible under the common keying approach. In the event that an individual cryptographic key is compromised under the unique keying approach, only the data streams associated with that key may be observed, and the rest of the network remains secure. However, the unique keying approach requires an onerous level of configuration and maintenance.

Under the unique keying approach, a unique cryptographic keypair may be generated for each host participating on the network and a public key for each machine on the network may be distributed to all other hosts on the network before any hosts can communicate with each other. When a new host is added to the network, the new host may be configured with the existing public keys of all existing hosts on the network and the new host's public key may be distributed to the existing hosts. In the event that a key regeneration event occurs under the unique keying approach, a new keypair may be generated for every host and distributed to every other host on the network. If a single host does not undergo this process during a key regeneration event, all communications to and from that host may cease because the other hosts on the network may not be able to encrypt traffic in a way that host can decrypt, nor can the other hosts decrypt traffic that the overlooked host encrypted using outdated keys.

Systems and methods as described herein provide, in examples, mechanisms that provide unique-per-host end-to-end encryption, which automates key generation, distribution, and regeneration in such a way that hosts connected to the network server never need to be manually reconfigured to accommodate additional hosts or entire network rekey events. It also allows for automated rekeying to occur on an on-demand ad hoc basis, or on a predetermined schedule. In some embodiments, systems and methods herein provide transparent capture of network traffic in order to preemptively establish a cryptographic relationship with the destination host of that traffic before allowing the traffic to proceed. In some embodiments, a 1:1 overlay network is used to facilitate automated calculation of destination host addresses. Some embodiments enable the ability to add new hosts into an encrypted network and for them to begin operating immediately.

Systems and methods as described herein may operate in two modes, comprising a kernel network module mode (e.g., a wireguard mode), and a solo mode. In a kernel network module mode, the encryption of the network traffic itself is handed off to the kernel network module (e.g., a wireguard module), which is incorporated into the network driver stack of the underlying operating system. In a solo mode, network traffic handling (encryption and decryption) may be handled by a secure communication program (e.g., Charon) itself. Cryptographic key management (including creation, dissemination, and regeneration) is handled identically under both modes.

FIG.1is a flow diagram100depicting an example computer implemented method to facilitate transparent end-to-end network public key encryption. At100, a network packet is received in a queue to be processed. Upon receiving the network packet, network metadata associated with the network packet is examined to determine an Internet Protocol (IP) address of a destination host. At102, an internal lookup table or database is queried to determine whether there is an already known valid cryptographic public key associated with the destination host. If a valid cryptographic public key associated with the destination host exists, it is returned by the query.

If a known valid cryptographic public key associated with the destination host is returned by the query, the network packet is handed off to an internal handler in accordance with a mode (a kernel network module mode or a solo mode) in which the system is configured to run at102to be processed using the known valid cryptographic key.

If there is no known valid cryptographic public key associated with the destination host, it is determined whether this is a first packet destined for that host at103. If the network packet is the first network packet addressed to the destination host, a queue is designated for the destination host and the network packet is added to the queue at104. At105, a unique identifier is calculated based on an IP address of the destination host. In some embodiments, the unique identifier is a cryptographic hash based on the destination IP address. In some embodiments, the cryptographic includes a shared secret (e.g., a string, a number representative of a network name). At106, a key management server is queried to return a cryptographic public key associated with the unique identifier. In some embodiments, the key management server is running a Conclave key management server software, as described in U.S. Patent Application Nos. 62/666,424 and 16/401,498, both of which are incorporated by reference herein. At102, the public key and all queued network packets addressed to the destination host are handed off to an appropriate traffic handler (either a kernel network module mode or a solo mode) to be processed.

If there is no known valid cryptographic public key associated with the destination host and the network packet is not the first network packet addressed to the destination host, the network packet is added to an internal queue already associated with the destination host at108until a valid cryptographic public key associated with the destination host is available. At102, the public key and all queued network packets addressed to the destination host are handed off to an appropriate traffic handler (either a kernel network module mode or a solo mode) to be processed upon a valid cryptographic public key associated with the destination host becoming available.

At109, the destination host decrypts the network packet using a cryptographic private key associated with the destination host upon the destination host receiving the network packet encrypted with a cryptographic public key associated with the destination host. In some embodiments, if the network packet contains a message indicating that a cryptographic public key associated with a sending host which sent the network packet is no longer valid, the destination host deletes the sending host's cryptographic public key from an internal key lookup table of the destination host. The destination host then treats subsequent traffic to the sending host as if it is a first network packet destined for the sending host.

FIG.2is a block diagram200depicting an example topology and set of operations to facilitate transparent end-to-end network public key encryption. A network packet201contains a message202and metadata203. The metadata203contains a destination host Internet Protocol (IP) address204of a destination host on the network to which the network packet201is addressed. At250, the network packet201is received by a host205on the network. Upon receiving the network packet201, an operating system kernel206of the host205places the network packet201on a first in first out queue207.

At251, a secure communication application (e.g., Charon)208running on the host205monitors the first in first out queue207and when the network packet201becomes available, the secure communication application208processes the network packet201. At252, the secure communication application208examines the metadata203of the network packet201to determine the destination host IP address204of the network packet201. At253, the secure communication application208queries an internal key lookup table209to determine whether there is already a known cryptographic key associated with the destination host.

If the internal key lookup table209contains a cryptographic public key210associated with a destination host211, the secure communication application208hands the network packet201off to an internal handler212at253. The internal handler212then sends the network packet201to the destination host211at254according to a designated traffic handler mode (a kernel network module mode or a solo mode).

If the internal key lookup table209does not contain a cryptographic public key associated with a destination host213and the network packet201is a first packet addressed to the destination host213, the secure communication application208places the network packet201into a queue214. At255, the secure communication application208calculates a unique identifier215based on the destination host IP address204of the network packet201and queries a key management server216for a cryptographic public key217for the destination host213. In some embodiments, the key management server is running a Conclave key management server software, as described in U.S. Patent Application Nos. 62/666,424 and 16/401,498, both of which are incorporated by reference herein. Upon receiving the cryptographic public key217for the destination host213from the key management server216at255, the secure communication application208hands the network packet201to the internal handler212at253. The internal handler212then sends the network packet201to the destination host213at254according to a designated traffic handler mode (a kernel network module mode or a solo mode).

If the internal key lookup table209does not contain a cryptographic public key associated with a destination host218and the network packet201is not a first packet addressed to the destination host218, the secure communication application208places the network packet201into a queue219designated for the destination host218. Upon receiving a public key220associated with the destination host218, the secure communication application208then hands off any queued data packets in the queue219to the internal handler212at253. The internal handler212then sends the network packet201to the destination host213at254according to a designated traffic handler mode (a kernel network module mode or a solo mode).

At254, the internal handler212encrypts the network packet201before sending an encrypted network packet219over the network to the destination host (e.g.,211,213,218) according to the designated traffic handler mode. In some embodiments (e.g., a kernel network module mode), the internal handler212encrypts the network packet201using the cryptographic public key (e.g.,210,217,220) associated with the destination host (e.g.211,213,218). In some embodiments (e.g., a solo mode), the network packet201is encrypted using a cryptographic symmetric key.

Upon receiving the encrypted network packet219at the destination host (e.g.211,213,218) at256, the encrypted network packet219is decrypted by the destination host (e.g.211,213,218). In some embodiments, the destination host (e.g.211,213,218) receives an encrypted packet219encrypted with a cryptographic public key (e.g.,210,217,220) of the destination host (e.g.211,213,218), whereupon the encrypted packet219is decrypted using a cryptographic private key associated with the destination host (e.g.211,213,218). In some embodiments wherein the encrypted network packet219is encrypted with a symmetric key, the destination host (e.g.211,213,218) decrypts the encrypted network packet219using the symmetric key.

FIG.3is a flow diagram300depicting an example computer implemented method for establishing a connection of a host to a transparent end-to-end network with public key encryption. When a new host attempts to connect to the network, a secure communication application running on the host first generates a cryptographic key pair for itself at301comprising a cryptographic public key and a cryptographic private key for the host. At302, the secure communication application stores the cryptographic key pair comprising the cryptographic public key and the cryptographic private key on a permanent storage media. At303, the secure communication application establishes a connection to a key management server. In some embodiments, the key management server is running a Conclave key management server software, as described in U.S. Patent Application Nos. 62/666,424 and 16/401,498, both of which are incorporated by reference herein. At304, the secure communication application transmits its own cryptographic public key to the key management server along with a unique identifier calculated by the secure communication application based upon an IP address of the host on which the secure communication application is running.

In embodiments, the secure communication application then executes commands which make use of available system configuration to direct network traffic that is destined for a particular destination host or set of destination hosts (e.g., an entire network or subnetwork) to be routed to a queue for processing and disposition by the secure communication program before being released to traverse a network. Thereafter, when a network packet, which would normally be sent to another host on the network is received by a network stack on the host running the secure communication application, an operating system kernel places the network packet on a first-in-first out queue, which is accessible to the secure communication application.

FIG.4is a block diagram400depicting an example topology and set of operations for establishing a connection of a host to a transparent end-to-end network with public key encryption. In the block diagram400, a new host401establishes a connection to the transparent end-to-end network. A secure communication application402generates a cryptographic key pair403associated with the host401comprising a cryptographic private key404and a cryptographic public key405. At450, the secure communication application402stores the cryptographic key pair403associated with the host401at an accessible location on a permanent storage medium406on the host401.

At451, the secure communication application402calculates a unique identifier407for the host401based on an IP address408for the host401. At452, the secure communication application402establishes a client-server connection to a key management server409. In some embodiments, the key management server is running a Conclave key management server software, as described in U.S. Patent Application Nos. 62/666,424 and 16/401,498, both of which are incorporated by reference herein. After establishing the connection at452, the secure communication application402transmits the unique identifier407for the host401in association with the cryptographic public key405.

FIG.5is a flow diagram500depicting an example computer implemented method to facilitate a key regeneration event to generate a new and different key pair for a host. In some embodiments, the key regeneration event may be initiated ad hoc by a user. In some embodiments, the key regeneration event is initiated according to a configured schedule. Upon initiating the key regeneration event, in an example embodiment, a secure communication application running on a host executes the following steps.

At501, the secure communication application receives a message initiating a key regeneration event from a user or a configured schedule. At502, the secure communication application deletes the cryptographic key pair associated with the host on which the secure communication application is running comprising a cryptographic public key and a cryptographic private key. At503, the secure communication application generates a new cryptographic key pair comprising a new cryptographic public key and a new cryptographic private key. At504, the secure communication application transmits the new cryptographic key pair to a key management server in accordance with the key management server's application programming interface. In some embodiments, the key management server is running a Conclave key management server software. At505, the secure communication application transmits a message to each destination host, with the message being individually encrypted with a cryptographic public key of each destination host, wherein the message indicates that the previous cryptographic public key for the host regenerating its cryptographic key is no longer valid.

At506, upon receiving a network packet at a destination host encrypted with a cryptographic public key associated with the destination host, the network packet is decrypted using a cryptographic private key associated with the destination host. At507, the destination host deletes a cryptographic public key associated with a sending host from which the network packet originated upon receiving a message indicating that the cryptographic public key associated with the sending host is no longer valid. At508, the destination host treats subsequent traffic to the sending host as if it is the first network packet destined for that host.

FIG.6is a block diagram600depicting an example topology and set of operations to facilitate a key regeneration event to generate a new and different key pair for a host601. To begin a key regeneration event, the host601receives a message from a user or a configured schedule, wherein the message directs the host601to execute a key regeneration event. Upon receiving the message directing the host601to execute a key regeneration event, a secure communication application602running on the host601deletes an old cryptographic key pair603stored on a permanent storage medium604at650. Upon deleting the old cryptographic key pair603, the secure communication application602generates a new cryptographic key pair605corresponding to the host601comprising a new cryptographic private key606for the host601and a new cryptographic public key607for the host601. At651, the secure communication application602stores the new cryptographic key pair605comprising the new private key606and the new public key607on the permanent storage medium604.

At652, the secure communication application602deletes an old cryptographic public key608of the old cryptographic key pair603associated with the host601from a key management server609. In some embodiments, the key management server is running a Conclave key management server software, as described in U.S. Patent Application Nos. 62/666,424 and 16/401,498, both of which are incorporated by reference herein. At652, the secure communication application also transmits the new cryptographic public key607associated with the host601to the key management server609and stores the cryptographic public key607on the key management server609.

In some embodiments, the secure communication application602accesses a cryptographic public key (e.g.,610,611) corresponding to each other host (e.g. 613, 614) on the network from an internal key lookup table612. At653and654, the secure communication application602encrypts a message (encrypted network packets617and618) to each other destination host (e.g.,613,614) on the network using the cryptographic public key (e.g.,610,611) associated with each host. The encrypted network packets617and618contain a message that the old cryptographic public key608associated with the host601stored on internal key lookup tables (e.g.,615,616) of the other destination hosts (e.g.,613,614) on the network is no longer valid. At655and656, each of the destination hosts (e.g.,613,614) decrypt the encrypted network packet (e.g.,617,618) they receive using a cryptographic private key (e.g.,619,620) associated with each destination host (e.g.,613,614).

Upon receiving the message that the old cryptographic public key608associated with the host601is no longer valid, each destination host613and614delete the old cryptographic public key608from their respective internal key lookup tables615and616at657and658. The destination hosts613and614treat any subsequent traffic to host601as if it is a first network packet addressed to host601.

FIG.7is a block diagram700depicting an example topology and set of operations to facilitate transparent end-to-end network public key encryption in a kernel network module mode. In the example block diagram700, a host701and a host702are located on a network with a class-B network size of 16 bits (10.8.0.0/16), meaning that valid addresses for hosts on the network range from 10.8.0.0.1 to 10.8.255.254, with 10.8.255.255 being a reserved broadcast address for every host on the network. In the example block diagram700, the host701has an IP address703of 10.8.1.1 and the host702has an IP address704of 10.8.2.2.

A key management server705is configured such that it is accessible by both host701and host702. In some embodiments, the key management server705is configured to run a Conclave key management server software, as described in U.S. Patent Application Nos. 62/666,424 and 16/401,498, both of which are incorporated by reference herein. In some embodiments, the key management server is on the same network as the host701and the host702. In some embodiments, the key management server may be located on a separate network from host701and host702, but still accessible by both host701and host702. In some embodiments, the key management server may be accessed by host701and host702by a resolvable network name706, such as, for example, “concalve.domain.com.” Both host701and host702are configured to use key management server705as their key management server at startup. In some embodiments, the host701and the host702are configured to use the key management server705using the resolvable network name706of the key management server705.

The host701and the host702have a kernel network module virtual network device707and708configured for each host, respectively. In some embodiments, the kernel network module virtual network devices707and708are configured with an overlay IP address709and710that match the underlying physical IP addresses703and704of the host701and the host702, respectively, mapped to a 1:1 overlay network address space. For example, if an underlying network address space is 10.8.0.0/16 and the overlay network address space is 10.9.0.0/16, then a host with a physical network IP address of 10.8.1.22 would have a kernel network module virtual network device configured with an IP address of 10.9.1.22. In the example block diagram700, the kernel network module virtual network device707associated with host701has an overlay IP address709of 10.9.1.1, corresponding to the IP address703for the host701of 10.8.1.1. The kernel network module virtual network device708associated with host702has an overlay IP address710of 10.9.2.2, corresponding to the IP address704for the host702of 10.8.2.2.

A domain name server711is configured to return the overlay IP addresses (e.g.,709,710) in the overlay network (10.9.0.0/16) for all hosts on the network (e.g.,701,702). Each listing in the domain name server711corresponds to a single host, containing a hostname and an associated overlay IP address for a corresponding kernel network module virtual network device for each host. For example, the host701is listed in the domain name server711as a hostname712associated with the host701of the example hostname “host1.domain.com” along with the overlay IP address709associated with the host701. The host702is listed in the domain name server711as a hostname713associated with the host701of the example hostname “host2.domain.com” along with the overlay IP address710associated with the host702.

When a host, such as the host701starts up for the first time, a secure communication application714running on the host701determines that this is the first time the secure communication application714has been run, meaning the host701does not have any cryptographic keys associated with it yet. The secure communication application714then determines from a configuration file that it will operate in a kernel network module mode. The secure communication application714then directs an underlying operating system kernel725to direct any network packets addressed to hosts on the overlay network (for example, addressed to an overlay IP address 10.9.x.x) to a queue726accessible by the secure communication application714. The secure communication application714then generates a cryptographic key pair715associated with the host701comprising a cryptographic private key716and a cryptographic public key717. At750, the secure communication program711creates a unique identifier718associated with the host701based on a cryptographic hash of the IP address703and a previously configured network name.

At751, the secure communication application714establishes a connection to the key management server705, creates an account for itself using an API of the key management server705, and registers the host701using the unique identifier718associated with the host701. Also at751, the secure communication application714uploads the cryptographic public key717associated with the host701to the key management server705, where it is stored in relation to the unique identifier718associated with the host701. After uploading the cryptographic public key717to the key management server705, the secure communication application714goes dormant and waits for network traffic addressed to any host on the 10.9.x.x network.

The host702undergoes the same process when it starts up for the first time. A secure communication application719running on the host702determines this is the first time it has been run determines that it will operate in a kernel network module mode from a configuration file. The secure communication application714then directs an underlying operating system kernel727to direct any network packets addressed to hosts on the overlay network (for example, addressed to an overlay IP address 10.9.x.x) to a queue728accessible by the secure communication application714. The secure communication application719then generates a cryptographic key pair720comprising a cryptographic private key721and a cryptographic public key722associated with the host702. At752, the secure communication application creates a unique identifier723associated with the host702based on a cryptographic hash if the IP address704of the host702and a previously configured network name.

At753, the secure communication application719establishes a connection to the key management server705, creates an account for itself using an API of the key management server705, and registers host702using the unique identifier723. Also at751, the secure communication application719uploads the cryptographic public key722associated with the host702to the key management server705, where it is stored in relation to the unique identifier723associated with the host702. After uploading the cryptographic public key722to the key management server705, the secure communication application719goes dormant and waits for network traffic addressed to any host on the 10.9.x.x network.

When a user on a host on the network wishes to access a network resource on another host, the following process occurs. In the following example, a user on the host701accesses a network resource on the host702, however, the process may be executed between any two hosts on the network. The user on the host701first enters the hostname713of the host702with which the user wishes to communicate. In some embodiments, the host701does not know the overlay IP address710of the host702. Therefore, the host701queries the domain name server711for the overlay IP address710associated with the hostname713of the host702at754. The domain name server711returns the overlay IP address710in response to the query. In some embodiments, the host701stores the overlay IP address710and the corresponding hostname713of the host702on an internal name server724located on the host701.

Upon receiving the overlay IP address associated with the host702, the host701attempts to establish a connection to the kernel network module virtual network device708associated with the host702. The host701attempts to make the connection through the kernel network module virtual network device707because the overlay IP710conveys to the host701that it is communicating on an overlay network, meaning its kernel network module virtual network device707on the overlay network should be used. At755, an initial network packet729addressed from the overlay IP address709(10.9.1.1) of the kernel network module virtual network device707to the overlay IP address710(10.9.2.2) of the kernel network module virtual network device708is placed into the queue726accessible by the secure communication application714.

At756, the internal communication application714then extracts a destination address (Overlay IP address710) from the packet and queries an internal key lookup table730to determine if the overlay IP address710is a known host with which it has previously communicated. If previous communication with the overlay IP address710had occurred, the overlay IP address710exists as an entry to the internal key lookup table730along with the cryptographic public key722of the host702associated with the kernel network module virtual network device708.

If the internal key lookup table does not contain an entry for the overlay IP address710, the secure communication application714obtains the cryptographic public key722of the associated host702. To obtain the cryptographic public key722, the secure communication application places the network packet729and any subsequent packets addressed to the overlay IP address710into a buffer731associated with the overlay IP address710at757. At758, the secure communication application714calculates the unique identifier723for the host702to which the network packet729is addressed based on the network name and the overlay IP address710and queries the key management server705for the cryptographic public key722associated with the host702using the newly calculated unique identifier723associated with the host702. The host701then awaits a response from the key management server705.

Upon receiving the cryptographic public key722associated with the destination host702, whether from the internal key lookup table730at756or from the key management server at758, the secure communication application714configures a kernel network module732to indicate that the overlay IP address710is associated with the cryptographic public key722at759. In some embodiments, the kernel network module (e.g., a wireguard module) may be a third-party software package. The secure communication application then calculates the underlying physical network address of the overlay IP address710(10.9.2.2), resulting in calculating the IP address704(10.8.2.2) of the host702. Upon calculating the IP address704, the secure communication program crafts and encrypts a network packet734and sends the network packet734to the host702at760. The network packet734contains a message735containing the overlay IP address709and the cryptographic public key717associated with the host701. The network packet734is encrypted with the cryptographic public key722associated with the host702at760.

At761, the secure communication application719running on the host702decrypts the network packet734using the cryptographic private key721associated with the host702upon receiving the network packet734. After decrypting the network packet734, the secure communication application719configures a kernel network module736on the host702at762indicating that the overlay IP address709is associated with the cryptographic public key717associated with the host701. At this point, both hosts are capable of encrypted communication with each other.

After establishing a connection, the secure communication program714dequeues the network packet729from the queue726along with any other packets in the queue726waiting for the connection to host702to become available and hands the network packet729and any other network packets from the queue726off to an operating system network stack737to process at763. At764, the network packet729and any other network packets from the queue726are sent to the kernel network module virtual interface device738.

At765, the kernel network module Virtual Interface738sends the network packet729and any other network packets from queue726to the kernel network module Instance736associated with the host702using a kernel network module encryption protocol. Under a kernel network module encryption protocol, the network packet729and any other network packets from queue726are each encrypted at765using the cryptographic public key722associated with the host702and sent as an encrypted network packet(s)739. At766, the encrypted network packet(s) is received by the kernel network module736and decrypted using the private key721corresponding to the host702and a resulting decrypted network packet(s) is handed off to an operating system network stack740of the host702at767.

At767, the kernel network module736hands the decrypted network packet(s) off to an HTTP port741(for example, HTTP port80in some embodiments) on the operating system network stack740and are received by an HTTP server742on the host702.

In some embodiments, the HTTP server742on the kernel network module virtual network device708responds to the kernel network module virtual network device707, which sent the encrypted network packet739. A response network packet is then handed to the kernel network module736at768. The response network packet is then encrypted with the public key717corresponding to the host701to create an encrypted response network packet743, which is sent to the kernel network module732, where the encrypted response network packet743is decrypted using the cryptographic private key721associated with the host702and handed off to an appropriate application (for example, a web browser in some embodiments).

FIG.8is a block diagram800depicting an example topology and set of operations to facilitate transparent end-to-end network public key encryption in a solo mode. In a solo mode, no overlay network is used. Therefore, it is possible to use a solo mode to secure communications between hosts that do not share a common local area or wide area network.

In the block diagram800, the example topology and operations secure communications between a host801and a host802, which may be located on disparate networks. The host801has an IP address803(1.2.3.4) and the host802has an IP address804(4.5.6.7).

A key management server805is configured on a network. In some embodiments, the key management server805is configured with an internet connection. In some embodiments, the location of the key management server805does not matter as long as the key management server805is accessible via the network from both the host801and the host802. In some embodiments, the host801and the host802may access the key management server805using a resolvable network name806(e.g., conclave.domain.com) of the key management server805. In some embodiments, the key management server805is running a Conclave key management server software, as described in U.S. Patent Application Nos. 62/666,424 and 16/401,498, both of which are incorporated by reference herein.

Hosts on the network are configured to execute a secure communication application at startup. The host801is configured to execute a secure communication application807at startup and the host802is configured to execute a secure communication application808at startup. The host801and the host802are each configured to use the key management server805as their key exchange server. In some embodiments, the host801and the host802are configured to use the key management server805by use of the resolvable network name806of the key management server805.

Upon the host801starting up and executing the secure communication application807for the first time, the secure communication application807determines that this is the first time it has been run and that the host801therefore has no cryptographic keys associated with it. The secure communication application807then determines from a configuration file that it will operate in a solo mode. The secure communication application generates a cryptographic key pair809comprising a cryptographic private key810and a cryptographic public key811suitable for use with a kernel network module. A unique identifier812for the host801is created by the secure communication application807based on a cryptographic hash of the IP address803of the host801and a network name813of the host801. In some embodiments, the network name813is configured by a system administrator.

At850, the secure communication application807establishes a connection to the key management server805and creates an account for the host801. In some embodiments, the account is created using an API for the key management server805. The secure communication application807registers the host801with the key management server805with the unique identifier812and uploads the public key811to the key management server805to be associated with the unique identifier812. The secure communication application807then goes dormant and waits for network traffic destined for any external host.

When the host802starts up and executes the secure communication application808for the first time, it follows the same steps. The secure communication application808determines that this is the first time it has been run and that the host802therefore has no cryptographic keys associated with the host802. The secure communication application808generates a cryptographic key pair814comprising a cryptographic private key815and a cryptographic public key816suitable for use with a kernel network module. A unique identifier817for the host802is created by the secure communication application808based on a cryptographic hash of the IP address804of the host802and a network name818of the host802. In some embodiments, the network name813is configured by a system administrator.

At851, the secure communication application808establishes a connection to the key management server805and creates an account for the host802. In some embodiments, the account is created using an API for the key management server805. The secure communication application808registers the host802with the key management server805with the unique identifier817and uploads the public key816to the key management server805to be associated with the unique identifier817. The secure communication application808then goes dormant and waits for network traffic destined for any external host.

When a user on the host801wishes to access a network resource on the host802, the user enters a network name818associated with the host802. The host801does not know the IP address804associated with the host802. Therefore, at852, the host801queries a domain name server819, which responds as configured and indicates that the network name818has an IP address804associated with it. The network name818and the IP address804returned by the domain name server are then stored on an internal name server826

The host801then attempts to initiate a connection to the IP address804. At startup, the secure communication application807had directed an underlying operating system kernel to direct traffic to external hosts to a queue820with which the secure communication application807can interact. The secure communication application807receives a network packet821to be sent from the host801to the host802and places it in the queue820, where it extracts a destination address for the network packet821, which in this example is the IP address804corresponding to the destination host802. At853, the secure communication application807queries an internal key lookup table822on the host801to determine if it contains the IP address804, which would indicate that the host802associated with the IP address804is a known host with which it has already communicated. The first time a network packet is sent to the host802, the internal key lookup table822does not contain an entry for the host802containing the IP address804. Therefore, the secure communication application807determines it should obtain the public key816associated with the host802.

At854, the secure communication application807places the network packet821and any subsequent packets it receives that are addressed to the IP804into a buffer823associated with the host802. At855, the secure communication application807calculates the unique identifier817associated with the host802based on a cryptographic hash of the IP address804of the destination host802to which the network packet821is addressed and the network name. Also at855, the secure communication application queries the key management server805using the unique identifier817that it just calculated, requesting the public key816associated with the host802and waits for a response. At856, the public key816associated with the host802and the corresponding unique identifier817is returned to the secure communication application807from the key management server805.

Upon receiving the public key816at856, the secure communication application807generates a symmetric key824to be used in communication between the host801and the host802. At857, the symmetric key824and the public key816associated with the host802are stored in the internal key lookup table822in relation with the IP address804associated with the host802.

At858, the secure communication application807creates a message825containing the IP address803and the public key811of the host801along with the symmetric key824to be used to communicate between the host801and the host802. The message825is encrypted with the public key816for the host802and sent to the host802at858. The message825is received by the secure communication application808and decrypted at859using the private key815associated with the host802. After receiving and decrypting the message825at859, the secure communication application808creates an entry in an internal key lookup table827on the host802wherein the public key811of the host801and the symmetric key824for communication between the host801and the host802are stored in relation with the IP address803of the host801. At this point, the host801and the host802are able to communicate with each other in a solo mode.

At861, the secure communication application807dequeues the network packet821from the buffer823along with any other network packets in the buffer823waiting for a connection to the host802to become available. For each packet from the queue823addressed to the IP address804associated with the host802, the secure communication application807encrypts the packet821using the symmetric key824generated for communication between the host801and802at861. At862, the secure communication application807sends an encrypted network packet828comprising the network packet821encrypted with the symmetric key824to the secure communication application808running on the host802.

The secure communication application808running on the host802receives the encrypted packet828at863. At864, the secure communication application808determines that the host801sent the encrypted network packet828and its associated IP address803. Upon determining the IP address803of the sending host801at864, the secure communication application808queries an internal key lookup table827using the IP address803of the host801which sent the network packet828and returns the symmetric key824generated for communication between the host801and the host802. Upon receiving the symmetric key824, the secure communication application808decrypts the encrypted network packet828using the symmetric key824.

At865, the network packet821comprising a decrypted product of the encrypted network packet828is placed into a network stack829of an underlying operating system using a raw socket. The network packet821is received by an HTTP server830on a port831(e.g., Port80) on the host802and given to a process listening on port831.

When the HTTP Server830on the host802responds to the host801, the secure communication application808determines there is an established relationship with the host801by locating the IP address803associated with the host801as an entry in the internal key lookup table827at866and using the associated symmetric key824for communication between the host801and the host802to encrypt a network packet to be sent to the host801. At867, the secure communication application808sends an encrypted network packet832to the secure communication application807on the host801. Upon receiving the encrypted network packet832at868, the secure communication application807decrypts the encrypted network packet832using the symmetric key824stored in the internal key lookup table824for communication between the host801and the host802. After decrypting the encrypted network packet832, the secure communication application897hands data decrypted from the encrypted network packet832to an appropriate application, for example, a web browser, in some embodiments.

Various implementations of the subject matter described herein may be realized in digital electronic circuitry, integrated circuitry, specially designed ASICs (application specific integrated circuits), computer hardware, firmware, software, and/or combinations thereof. These various implementations may include implementation in one or more computer programs that are executable and/or interpretable on a programmable system including at least one programmable processor, which may be special or general purpose, coupled to receive data and instructions from, and to transmit data and instructions to, a storage system, at least one input device, and at least one output device.

These computer programs (also known as programs, software, software applications or code) include machine instructions for a programmable processor, and may be implemented in a high-level procedural and/or object-oriented programming language, and/or in assembly/machine language. As used herein, the term “machine-readable medium” refers to any computer program product, apparatus and/or device (e.g., magnetic discs, optical disks, memory, Programmable Logic Devices (PLDs)) used to provide machine instructions and/or data to a programmable processor, including a machine-readable medium that receives machine instructions as a machine-readable signal. The term “machine-readable signal” refers to any signal used to provide machine instructions and/or data to a programmable processor.

To provide for interaction with a user, the subject matter described herein may be implemented on a computer having a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user and a keyboard and a pointing device (e.g., a mouse or a trackball) by which the user may provide input to the computer. Other kinds of devices may be used to provide for interaction with a user as well; for example, feedback provided to the user may be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user may be received in any form, including acoustic, speech, or tactile input.

The subject matter described herein may be implemented in a computing system that includes a back-end component (e.g., as a data server), or that includes a middleware component (e.g., an application server), or that includes a front-end component (e.g., a client computer having a graphical user interface or a Web browser through which a user may interact with an implementation of the subject matter described herein), or any combination of such back-end, middleware, or front-end components. The components of the system may be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include a local area network (“LAN”), a wide area network (“WAN”), and the Internet.

The computing system may include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other.

In the descriptions above and in the claims, phrases such as “at least one of” or “one or more of” may occur followed by a conjunctive list of elements or features. The term “and/or” may also occur in a list of two or more elements or features. Unless otherwise implicitly or explicitly contradicted by the context in which it is used, such a phrase is intended to mean any of the listed elements or features individually or any of the recited elements or features in combination with any of the other recited elements or features. For example, the phrases “at least one of A and B;” “one or more of A and B;” and “A and/or B” are each intended to mean “A alone, B alone, or A and B together.” A similar interpretation is also intended for lists including three or more items. For example, the phrases “at least one of A, B, and C;” “one or more of A, B, and C;” and “A, B, and/or C” are each intended to mean “A alone, B alone, C alone, A and B together, A and C together, B and C together, or A and B and C together.” In addition, use of the term “based on,” above and in the claims is intended to mean, “based at least in part on,” such that an unrecited feature or element is also permissible.

The subject matter described herein can be embodied in systems, apparatus, methods, and/or articles depending on the desired configuration. The implementations set forth in the foregoing description do not represent all implementations consistent with the subject matter described herein. Instead, they are merely some examples consistent with aspects related to the described subject matter. Although a few variations have been described in detail above, other modifications or additions are possible. In particular, further features and/or variations can be provided in addition to those set forth herein. For example, the implementations described above can be directed to various combinations and subcombinations of the disclosed features and/or combinations and subcombinations of several further features disclosed above. In addition, the logic flows depicted in the accompanying figures and/or described herein do not necessarily require the particular order shown, or sequential order, to achieve desirable results. Other implementations may be within the scope of the following claims.