Patent Application
20250240175
This invention relates generally to computer networks and associated methods, and more particularly to solutions for building networked environments, and enabling systems and devices to communicate with one another in a secure manner. Embodiments also provide tools for efficient and secure creation, configuration, reconfiguration and/or maintenance of computer-based networks and systems, and for providing capabilities and functionalities which may have been provided by conventional VPN servers. Embodiments of the disclosure are particularly suited for providing enhanced security within an overlay network, by preventing possible exploits and attacks; and also for providing improved PKI management and DNS techniques.
The need for connectivity between computing systems for communication and data sharing is commonplace in today's world. Many arrangements use public key cryptography as a building block for the establishment of such connections. However, the use of public key cryptography and traditional approaches to network connectivity present a common set of logistical problems, including but not limited to: Identity validation, public key distribution, public key authenticity and peer discovery and peer connectivity. In situations involving mutually known and co-operating entities, the technical challenge becomes how to perform the exchange of public keys. A trusted third party e.g. Certificate Authority (CA) is not necessarily required for the participants to gain confidence of each other's identities during the public key exchange if they already share a real world relationship because the role of a CA is to provide identity assurance between entities that do not share a real-world relationship. However, if the CA is removed from the process then the parties do not benefit from the ability to utilise the easier-to-handle name-to-key mapping that is conventionally provided by the CA (e.g. a CA issued certificate maps the name example.com to a 2048 bit public key). Such parties wishing to connect without a CA face challenges relating to public key exchange, network discovery, system reachability and other technical difficulties. Thus, it is desirable to provide a solution which: address at least these challenges and more; enables reliable, simple and efficient public-key distribution between parties; removes the requirement on administrators in a network to a) manage intent and b) require a pre-existing real-world relationship to exchange intent to connect; and enables network connectivity to be constructed, maintained and utilised in an efficient, quick, secure and simple manner.
The following terms will be used hereafter in this document.
Illustrative embodiments of the present disclosure are provided herein in the description and appended claims. The disclosure provides mechanisms for connecting systems to one another for subsequent communication and data sharing. Upon connection, the systems form a Virtual Private Network (VPN) without a centralised component to acting as a traffic concentrator or typical VPN server and gateway as known in the art. Each system adds a virtual network interface (VIF) to their respective side of the connection and assigns itself or is assigned a virtual IP address. This enables the establishment of a directly connected, end-to-end encrypted connection, providing a virtual overlay network that is common to, and shared by, each system. As a result, the secure, direct connection is established without the traditional need for VPN server in the middle.
Preferably, a Platform is provided by means of a SaaS service (Software as a Service) which facilitates introductions and connectivity between the systems. The systems may or may not belong to the same organisation. Preferably, the Platform comprises one or more of: a Discovery Service (DS), an interface resource which serves as a portal for account management and configuration of settings, a Certificate Authority (CA) and/or a plurality of Relay Services which may function substantially as the equivalent of TURN servers.
The Platform provides a mechanism for controlling and categorising systems via the use of “Tags” and “Policies”, which are described in more detail below. In brief, though: a “Policy” may be applied to one or more systems to specify traffic flow conditions which apply to them. For example, a condition may be “network traffic may only flow between specified systems on Monday between 10 am and 11 am GMT”. A Policy may be composed of one or more Tags on the “Sender” and also the “Receiver” side of the Policy. The Tags may govern the direction in which traffic may flow (sender toward receiver). Tags may contain Tag Membership Requirements such as, for example, “is antivirus protection enabled?”. Preferably, only pre-authorised Account Owner(s), Platform Administrator(s) or other designated/delegated roles are able to define, specify or edit Policy conditions or Tags and Tag Membership Requirements.
An illustrative use-case scenario in accordance with a preferred embodiment is provided as follows. Carol registers with the Platform to create an account. Registration may be performed via an interface provided via any suitable means such as, for example, a web-based portal. A software application (i.e. “the Agent”) is then installed on each of the system(s) that she wants to enrol to the Platform. During or after installation, Carol obtains, from the Platform, one or more Enrolment Keys for her System(s) with the Agent installed. The Enrolment Keys provide a mechanism for enrolling each System into Carol's account at the Platform. The same Enrolment Key can be used on many systems, depending on how Carol chooses to configure the properties or attributes associated with the Enrolment Key.
In order to facilitate subsequent authentication of identity and authorisation to connect, each Agent generates a cryptographic key and sends this along with its Enrolment Key to the CA at the Platform in the form of a Certificate Signing Request (CSR). In contrast to traditional CAs, the CA of a preferred embodiment is “private” to the Platform in the sense that it is not, as per the prior art, provided by the Operating System (OS) supplier and pre-installed on the System at the OS level.
The CA generates a non-secret identifier, chosen at random (i.e. arbitrarily), that can be subsequently used as a Certificate Name on a digital certificate that can be sent back to a requesting party. The certificate name is similar to a Common Name as known in the prior art. Each Certificate Name is unique to a given public key and is stored in the CA's records in association with the Public Key. In some embodiments, but not all, the Certificate Name provides a more human-friendly short name for authentication and authorisation purposes compared to a cryptographic key.
Network reachability information is stored at the Platform for each system that has been enrolled. This reachability information, e.g. IP addresses and port number, provides a way for other Systems to locate, on the network, the System that a given Agent is installed on, and is refreshed each time the Agent (re) connects to the Platform (usually via the public Internet). Therefore, the network reachability information enables Agents installed on enrolled systems to locate and connect with each other following introduction via the Platform's Discovery Service.
After enrolment, if an enrolled system has been assigned Tags by Carol, the end-user (operator) of that system (i.e. Alice/Bob) cannot assume local control of that Agent on the System in respect of any connectivity the Agent may attempt to establish. Instead, the Agent is configured by Policy pushed from the Platform. If, however, the enrolled System is not tagged at the Platform, Alice may freely configure the Agent software to request a connection to other Enrolled Systems. However, the intent to connect must be reflected mutually i.e. reciprocated by the System to which Alice has attempted to connect. It is worth noting that the local user, Alice/Bob, may retain some control of the Agent on their System, although connectivity to other peers becomes governed and enforced by Policy as applied by Carol at the Platform (e.g. the ability to disable a connection established by Policy, or to stop and start the Agent software).
Thus, in a preferred embodiment, once a System has enrolled by requesting a Certificate from the CA in a single transaction which includes their Enrolment Key, its Agent opens a connection to the Discovery Service which thereafter acts as the “command and control” channel (which may also be referred to as a “signalling channel”). From one perspective, a System may be thought of as transitioning to being an “Enrolled Agent” after Certificate issuance.
When a connection attempt is initiated, the DS checks whether the System identified by the provided Certificate name is a managed or unmanaged one. It is Managed if one or more Tags are associated with it in the Organisation's Account, and unmanaged otherwise. If it is managed, the DS makes the necessary introductions to the other Enrolled Systems specified in the Policies that Carol has defined in the Platform by providing the relevant reachability information to all concerned Systems. The Systems then attempt to connect to one another. Techniques such as coordinated UDP/TCP hole punching (e.g. https://arxiv.org/abs/cs/0603074 and https://arxiv.org/pdf/cs/0603074.pdf) can be utilised for the purpose of establishing the network tunnel between the Agents in such a way as to avoid requiring them to open firewall ports or allow ingress traffic from the Internet to establish the a network connection.
An unencrypted network connection is established and is used as a communication medium over which the connecting systems may share their digital certificates, perform a key exchange handshake and agree a symmetric encryption key. The encryption key can then be used to provide end-to-end encryption of subsequent communication between the connected systems.
For example, suppose that System1 is governed by a Policy that mandates that it should be connected to System2. System1 and System2 both have respective Agents installed on them so they can be managed by the Platform. Typical steps may be:
Thus, the disclosure provides methods, Systems, platforms and/or infrastructure which facilitates machine-to-machine public-key distribution between parties that are willing and able to verify each other's identities. It also provides a mechanism for building functionality into the connectivity achieved following the verification and establishment of a communication channel between the respective parties. It also provides systems and methods for creation, configuration, control and maintenance of virtual networks.
According to one aspect, embodiments may be used to establish an encrypted Tunnel and provide virtual network interfaces at either end of the Tunnel so as to emulate a virtual private network (VPN) tunnel between connected Peers. Advantageously, this VPN may encapsulate data packets at layer 2 (using ethernet frames) or layer 3 (using ipv4/ipv6) without the need for a VPN server in the middle. Therefore, embodiments provide a significantly improved VPN architecture for connectivity establishment compared to the prior art. Various technical issues arise from this including, but not limited to, the requirement to provide effective protections against known exploits such as ARP cache poisoning. Solutions for addressing ARP cache poisoning are provided herein in accordance with this aspect of the disclosure, substantially in the section entitled “FAKE ARP” provided below. By way of short summary, in a preferred embodiment each Agent maintains a record of spurious MAC addresses that it has generated for systems that are enrolled with the Platform and that it is able to connect with. Each time a System wishes to send data to a given Peer, the Agent on that System will use the fake MAC address that it has generated and associated with that peer.
According to another aspect, embodiments may provide a software-based solution for addressing the technical challenges associated with the known approach to Domain Name System (DNS). The disclosed solution enables an entirely different mechanism to be constructed compared to the traditional DNS approach. As known in relation to the public Internet, zones are used as a mechanism for grouping sub-domains into hierarchical structures. In reality, however, those sub-domains are records within higher-level domains. Embodiments of the disclosure enable users to create zones within the VPN that is generated on the overlay network. By enabling users to create zones, the known functionality of the public Internet can be emulated on a VPN of an overlay network while providing the services associated with the use of traditional domains and sub-domains. In accordance with an illustrative embodiment, a Platform may be provided substantially as described herein to enable a plurality of enrolled Systems to communicate with one another over an overlay network that is constructed and managed via the Platform. In a preferred embodiment, a “stub resolver” is provided in association with, or as part of, an Agent that is installed on an enrolled System. This provides a mechanism for using a Tag that an administrator (Carol) has applied to a System to associate a domain name with an IP address, and also to resolve a domain name for the enrolled System to an IP address.
According to another aspect, embodiments may provide improvements and alternatives to the traditional PKI process. In the overlay network disclosed herein, when a new record (DNS name) is created and assigned to a System not only is that System itself informed of the name but all other Systems that are connected to it via its associated Tags and Policies also become aware of it.
Thus, knowledge of the assignment of that name to a one enrolled System propagates through to other enrolled Systems because of their pre-authorisation to connect with each other in the overlay network.
The steps of a preferred embodiment may comprise:
It should be noted that any feature described or claimed herein in relation to one aspect of the disclosure may also be present and incorporated into one or more other aspects of the disclosure.
Aspects and embodiments of the present disclosure will now be described, by way of example only, and with reference to the accompany drawings, in which:
In a preferred embodiment, and as shown in the accompanying figures, the disclosure provides a Platform (1) that includes some or all of the following components:
Some embodiments may be implemented partially or wholly as a cloud-based system and/or as a SaaS service. However, other embodiments may not comprise such components or aspects. In some embodiments, Platform components may be implemented using dedicated hardware and software provided in one or more datacentres. The disclosure is not limited with regard to any particular implementation architecture or service delivery mechanism.
We now describe illustrative embodiments of the disclosure which, referring to the Figures, provide mechanisms that enable systems to establish network connectivity between them. Preferred embodiments enable a direct, end-to-end encrypted Tunnel between Systems 6, 7 via the public Internet with a virtual network interface on each system operating at either Layer 2 or 3 in a manner that is transparent to existing applications.
In our example embodiments, Alice and Bob are operators of systems System1 and System2 respectively. These systems are managed (Tagged) in compliance with Policies that have been set by the Account Owner/administrator (Carol) and, therefore, do not need to provide further evidence of intent to connect. The Policies that are specified by Carol are pushed by the Platform's DS to the respective Agents installed on the Systems and dictate what the Agents (13) are permitted or not permitted to do with respect to connectivity to Agents on other Systems.
If an assigned Policy specifies that System1 should connect with System2, the Agent (13) on System1 (6) asks the DS (
In other words, the Agent on each System asks the DS to grant it a subscription to the other System by the other System's Certificate Common Name as given to it by a Policy push from the DS. When asked for a subscription, if the DS accepts the request, each Agent will be provided with a set of server reflexive Connection Candidates and a relay service Candidate that can be used to reach the other System on either the local network or Public Internet. Therefore, System1 requests a subscription to system2 at the DS. The DS may acknowledge the request. When
System2 makes a similar subscription request to the DS for an introduction to System1, the DS is then- and only then—is in a position to provide both parties with the network reachability information (set of Connection Candidates) required to attempt a direct connection between the two Systems. Thus, unless both Agents submit subscription requests simultaneously to create symmetric intent, an asymmetry will arise between subscription requests wherein an interval will emerge between a subscription request and the DS providing Connection Candidates to both Agents. A subscription must be required by both Systems, the interval between subscription and introduction might be in the order of milliseconds, weeks, months or might never arise. So, in use, a very small or very large amount of time may pass between a subscription request being made and an introduction, depending on whether both systems are online at the same time and when they both requesting their respective subscriptions. If the Agent on either System1 or System2 temporarily disconnects from the DS, it will ask again for the same set of peer subscriptions when it comes back online and reconnects to the DS. Similarly, if the tunnel between System1 and System2 is lost but one of them does not notice a network connectivity interruption on its side, the system's Agent will proactively re-request a subscription to the disconnected Peer.
With further reference to the Figures, we now explain various aspects, features and components of the disclosure in more detail.
Carol enrols Systems 1 and 2 with the Platform. Following registration, enrolled Agents on the respective systems will be able to use the Platform's services to enable construction of Tunnels with other Agents on other Systems that have also been enrolled. During the enrolment process in step 1 of
In some embodiments, an Enrolment Key might be limited or restricted to a specific number of uses. In other embodiments, an Enrolment Key might not have a limit in respect of the number of times it can be used. Moreover, an Enrolment Key might either be set to approve new enrolments automatically, or new enrolments may need to be manually approved by Carol before the enrolling system is accepted into the Platform.
Enrolment Keys are arbitrary, in that their values or format are not determined in respect of the System that they relate to and are generated by an algorithm that comprises a random or pseudo random key generation process. In an illustrative embodiment, an Enrolment Key may take the form:
An Enrolment Key allows the Agent (13) on a newly added system to interact with the Platform's Certificate Authority (
Therefore, from Carol's perspective, in order to enrol a particular System she performs the following steps:
The enrolled System subsequently follows the relevant connection flow for either “managed Agent mode” or “unmanaged Agent mode”. “Managed mode” is a connection flow that is governed by Tags and Policies. “Unmanaged mode” is a connection flow wherein Tags and Policies have not been specified for use with the System and therefore an explicit, out of band intention to connect must be established between or provided by System Administrators.
System enrolment is an additive or subtractive process in the sense that following creation of Carol's account, neither System1 nor System2 are known to the Platform. After the Agent software is installed on the relevant systems, Carol can then use the Platform's portal to start building and defining a network of connectable Systems for her organisation. When connectivity is subsequently established between her Enrolled Systems, the connection may be achieved using either the unmanaged technique disclosed in WO 2017/060675 (i.e. the “you tell me your certificate name and I will tell you mine” approach) or the centrally managed “Tags and Policies” approach described herein, and which involves the use of Policies and possibly Tags that are defined by Carol for specific Systems and pushed to those Systems at the appropriate time(s).
An Enrolment Key could be a single-use key for adding a System once and then the key is disabled. Alternatively, the key could be a multi-use key. Each Enrolment Key may apply an administrator configured set of initial (possibly default) set of Tags to an Enrolling System. Therefore, an Enrolment Key can be associated with a set of rights and rules (which we will describe below in the “Tags and Policies” section) and any System that is enrolled with that Enrolment Key will automatically inherit the associated rights, rules and constraints. This means that Carol does not need to manually define the rights, rules or constraints for each System upon enrolment, as the Platform can apply them automatically using the Enrolment Key. If the Tags to which an Enrolment Key applies are subsequently changed by Carol, this does not retrospectively affect the initial set of Tags applied to Systems that were previously enrolled using that same key. Therefore, Tag membership via an Enrolment Key can be viewed as a point-in-time snapshot of a Carol's decisions or management Policies.
Using the interface provided by the Platform's portal, Carol can designate an Enrolment Key for use with certain types of Systems. To facilitate this, the Platform allows Carol to attach a label or description to each of her Enrolment Keys. This makes it easier for Carol to recognise the Enrolment Keys and their designated purpose as “raw” keys are long strings of hexadecimal digits which are not easily handled by humans. For example, if Carol wishes to enrol a new laptop to her Organisation account she might use an Enrolment Key labelled “Laptop key” to enrol that system with the Platform.
In some but not all embodiments, Enrolment Keys may only apply Tags to Systems that are being enrolled if the following conditions are true:
Thus, in summary, an Enrolment Key identifies the organisation that an Enrolling System belongs to, and Carol can specify a set of “initial” Tags to be assigned to that key such that the set of Tags are applied to all subsequent systems which are enrolled using it. For example, consider an Enrolment Key that Carol labels as “All Staff Enrolment Key”. This could be configured to automatically apply the tag “all-staff” to Alice's laptop when it is enrolled using that particular Enrolment Key. This is, however, the extent of the relationship. Carol is able to add more Tags to the user's laptop e.g. “guest-computers”, “uk-laptops” etc. or she could remove some or all the Tags. The Enrolment Key is irrelevant and has no direct or lasting relationship with an Enrolled System.
Preferably, the Platform allows Carol to remove or disassociate a previously Enrolled System from an account. Over time Carol will most likely wish to reconfigure the state of connectivity defined at the Platform. Systems will be added or removed and Carol will need to maintain and reconfigure the remaining Systems enrolled with the Platform. This can be achieved by removing the link between the System and the account and/or Enrolment Key with which the System is associated at the Platform.
Therefore, the Platform provides a tool for the specification, configuration, re-configuration and/or update of a computer-based network. The disclosed use of the Enrolment Key reduces the amount of time, effort and processing resources required when specifying or reconfiguring the network. The described use of Enrolment Keys provides significant technical advantages, including but not limited to:
Following enrolment of a system with the Platform, Carol is able to be able to define the controls and/or requirements that she wishes to apply to that System. This is achieved using the “Tags and Policies” features of the present disclosure, and illustrated in step 4 of
From one perspective, a Tag can be described as a label for a category, class or type of enrolled System which allows Carol to group certain Systems together which share similar characteristics (i.e. business unit, security level or function). In this way, Tags can be viewed as denoting a System's membership within a group or class, and are binary in the sense that a given System is either a member of that defined Tag, or it is not. The relationship is many-to-many in that a particular System can be a member of multiple classes by having multiple Tags applied to it, and Tags can apply to multiple Systems.
Tags can be used to logically associate or group together Systems which share either a common function, role or purpose. The function may be a technical function or may be related to the operational activities of an organisation e.g. business entity, organisation or unit thereof (e.g. accounts team, developers, board members). A Tag may apply to Systems which share a common purpose or function (e.g. web servers, database servers) or a common security level (e.g. home workers, system administrators) or some other shared criteria or attribute. This shared attribute gives rise to a relationship that is reflected in the Tag membership.
Thus, Tags can be described as free-form text labels attached to one or more systems that are enrolled with an account on the Platform. Tags allow Carol or Platform Administrators to group or logically associate Systems which share similar characteristics (i.e. business unit, security level or function). They can be manually added to an enrolled System by Carol, or an Enrolment Key can be configured to apply an initial set of Tags to enrolling Systems.
Tags can include zero, one or more Tag Membership Requirements which define when and/or how a resource belongs to a Tag class. The Tag Membership Requirements may be encoded in machine executable form and subsequently enforced by Policy. For example, a Tag for “Guest laptop” may have the requirements that the Tag only applies if the tagged system:
It should be noted, though, that equally a Tag may have no Tag Membership Requirements at all and may still be valid, applied and effective.
Thus, via the use of Tag Membership Requirements, Carol can specify a granular level of constraints and permissions which apply to members of each Tag, and can specify when Systems become or cease to be active members of that Tag. Tag Membership Requirements are additive in the sense that they must all be met in order for a System to be counted as an active member of a Tag. For example, if Carol has associated a particular System with the “Guest laptop” Tag, and that System does not have anti-virus protection enabled as per the Tag Membership Requirements, it is not considered to be an active member of the Tag regardless of where it is located. Similarly, if a System tagged as “Guest laptop” does has antivirus protection enabled, it will still cease to be an active member of the “Guest laptop” Tag once it is known to have moved out of the permitted geographical location defined in the Tag Membership Requirements. (Geographical location may, for example, be determined using an IP lookup database although any known technique could be used).
In an example, suppose that a “Workstation” Tag is added to all Systems which function as user workstations within an organisation but Carol wishes to specify that the given Systems are should only inherit the relevant permissions for workstations while they are physically location within the office. For example, a work laptop may have certain connectivity to other Enrolled Systems when in the office, but not when travelling. Carol adds a “Public IP Address requirement” to the “Workstation” tag that specifies the public IP ranges of the office network(s). When any Systems tagged as “Workstation” connect to the Platform, the Platform attempts to validate the Tag requirement for that System. If the System is not at the office the validation fails and the “Workstation” tag temporarily disables for that particular System. When the laptop is brought back to the office and connects to the Platform, the Tag Membership Requirement is met and the “Workstation” Tag enables again for that System and, by extension, any Policies which reference that Tag thus restoring connectivity.
It should be noted, however, that Policies due to dynamic operating conditions and may only be disabled by a Platform Administrator or Carol. Whereas a Tag is either active or disabled for a given System at any given point in time, but the presence of that Tag in a Policy remains constant unless re-configured by a Platform Administrator or Carol. For example, the “Workstation” Tag may be applied to thirty different Systems that Carol has enrolled with the Platform. If one of those thirty Systems violates the Tag Membership Requirements of the “Workstation” Tag then the resulting change, i.e. disablement of the Tag, is constrained to that specific System only. A Policy which might specify that Systems tagged as “Workstations” should connect to Systems tagged as “Servers” would be unaffected by the change.
Preferably, the Tag-based approach may be implemented on a per System basis. In other words, if a System is removed from Tag Membership Requirements that may have a consequential effect on the application of a Policy. The Policy itself is not disabled, the System is simply disabled from Tag membership and, by extension, because the only relationship between a System and a Policy is via Tag membership the Policy ceases to apply to that particular System. Thus, Systems may be “active” or “inactive” in relation to a Tag. To use an alternative wording, a System's Tag membership can be active or inactive at a given point in time based on the dynamic state of a set of Tag Membership Requirements that each System may, or may not meet, and thus the applicability of a Tag to a given System is determined dynamically rather than being static. Tag membership can change from active to inactive and vice versa. For example, a particular System may have the tag “Office Workstations” applied to it by Carol or a Platform Administrator, but if that System is not in the office the System is simply not active in respect of the Tag, even though the Tag relationship remains.
Other, non-limiting and non-exhaustive examples of Tag Membership Requirements could include:
As explained above, Tag Membership Requirements can be dynamic and can apply/not apply at a given point in time. The status of “active” or “not active” with regard to Tag membership can be determined on an event-driven basis, such that a detected event can trigger a change of Tag membership status for a given System. The triggering event can be detected by an event listener or monitoring component, or can be communicated to the Platform from an internal or external source. For example, a GPS tracker may send a signal to indicate that a given System has been taken out of the office or other permitted geographic location, or an internal clock may indicate that a process has been running for a given length of time etc. The type or nature of possible Tag requirements is infinite and are configured by the Platform Administrator role or Carol.
An advantage of the Tag-based approach is that Carol does not need to define, apply and review the settings, permissions or controls for individual Systems. Instead, she can define a System as belonging to a particular logical group of Systems by applying a Tag to it and that System will then be bound by the Tag Membership Requirements of that Tag. This provides a simple, efficient and secure way of managing and controlling systems on a virtual network. Tags, however, become even more useful when used in conjunction with Policies.
Policies comprise Tags. In essence, a Tag is a way of applying Policies to Enrolled Systems without the need for individual settings for each System. Like Tags, Policies are also set by Carol or the Platform Administrator via the Platform's Portal interface. However, while Tags relate to Systems which share similar characteristics (e.g. because they belong to the same business unit or share a common security level or function) a System may be a compliant, or non-compliant member of a tag. System membership of specific Tags is binary in nature, a given System either is Tagged, or it is not. Policies, on the other hand, define rules which are applied to permit, restrict or deny the flow of information between Systems based on their Tag membership and compliance status with the Tag Membership Requirements. While Tag membership is defined on a per-System basis, Policies are defined at a global level within each Account and are composed of Tags. Systems which are “active” in respect of a given Tag may inherit one or more Policies which govern traffic flow and connectivity between said systems. Policies can be influenced or dictated by one or more factors. For example, these might include one or more of: System identity, end-user identity, point-in-time security attributes of the end-user's Systems and metadata or factors such as network location, geographic location, time of day and any other heuristics that might feed into a go-no go decision from the Policy engine.
By way of example, Laptop1 may be a member of the Tags: “uk-laptops”, “developers” and “all-staff”, while Laptop2 may be a member of the Tags: “uk-laptops”, “administrators”, “all-staff”. Carol may set the following Policies:
Thus, Policies define and constrain which Peers an Enrolled System can communicate with and how. If a particular Policy does not include a particular tag, then Systems with membership of the omitted tag will not have any connection to systems of Tags which are and no tunnel for communication will be established between them. Tags unreferenced by Policy and by extension any member Systems remain unaware of one-another and any connectivity implied by Policies which reference other Tags.
Enrolled Systems act independently of each other in accordance with the Policies that have been assigned to them by Carol and in response to the Policies that are computed and sent to them by the DS. If a Policy specifies that System1 should connect to System2, System1 will ask the DS for an introduction and vice versa with System2. However, System1 and System2 do this independently of one another without any shared knowledge of what the other is doing. In accordance with preferred embodiments of the disclosure, Policies specify when and how Systems within that Tag membership can connect, send and receive data. Traffic Rules govern Traffic Flows between Enrolled Systems and are specified as receive-oriented rules. In other words, Traffic Flow controls are only defined from the perspective of the receiver side of the Policy. Send-side restrictions are not defined because defining who can receive what and from whom also implies sender restrictions. A System may be a member of multiple or no Tags. Additionally, or alternatively, a Tag may be referenced by multiple or no Policies.
Preferably, the Platform is “default deny” with respect to visibility and Traffic Flow between Peers until a Policy is defined by Carol or a Platform Administrator that allows it. The Policy controls visibility and connectivity between Enrolled Systems. As these Systems are at either end of a communication channel, when viewed from the perspective of one of the systems they can be perceived as the sender or receiver of network traffic at a specific point in time.
A Tag attached to the Sender side of a policy that relates in some way to a receiver Tag implies that all sender Systems that have that Tag assigned have permission to connect with, and send data to, all of the receiving Systems that have the corresponding receiver Tags assigned. However, until a Tunnel is actually established between System1 and System2 the Traffic Flow is not enabled. In a default-deny configuration, Traffic Rules may be required to enable a Traffic Flow. Traffic Rules define the network traffic that is permitted between a given sender and receiver, and Traffic Rules can control a variety of connection behaviours. Examples of traffic rules may include, for example, but are not limited to:
In a preferred embodiment, a sender may initiate Traffic Flows to a receiver, by not vice versa. Traffic Flow restrictions (which are also known as access control lists or “ACLs”) are defined by Policy but only specified on the receiver side of that Policy. However, in practice, both sides of a connection apply the same Policy, and therefore if a Policy only permits System1 to receive a particular type of traffic from System2 (for example, tcp/3389 traffic, then System1 can only send tcp/3389 traffic to System2). The application of Traffic Rules happens at both ends of the Tunnel on the sender and the receiver side, even though Traffic Rules are defined only on the receive side of the Policy. The send side restrictions are implied by the Traffic Rules defined for the receiver side of the Policy.
The Policies described above may be implemented via a “Policy Engine”. The Policy engine may perform the following roles:
We now describe in detail how the connection process is performed in respect of two enrolling peers—System1 and System2—to establish a secure communication channel (
Once Systems 1 and 2 have been enrolled using their respective Enrolment Keys, they each open persistent connections (
In contrast to the disclosure of WO 2017/060675, this connectivity is achieved by a machine-to-machine, automated process facilitated by the Platform without the need for manual intervention. This provides the benefit of being easier, more efficient, secure and simpler for end users; it reduces the likelihood of human-originating errors and thus the time, resources etc required to establish the desired connectivity and communication channel. The solution also scales more effectively to larger groups of participants avoiding the need for each party to directly exchange Certificate Names with every other.
Thus, compared to conventional approaches, embodiments of the disclosure provide:
As shown in step 2 of
In line with standard network security practices, System1 and System2 may have firewalls or have routers which use network address translation (NAT) to protect their networks. Normally, if System1 has sent traffic out through its firewall, System2 is able to respond back to the Agent on System1 through System1's firewall due to an assumed permission based on System1′sinitial outbound communication. In the current scenario, when System1 tries to connect with System2, System2's firewall will reject System1′sunsolicitied communication. However, the DS makes an introduction between Systems 1 and 2 simultaneously, so when System2 also tries to communicate with System1 momentarily later, System2's communication appears to System1 to be a reply to its initial connection request packet and so System1′sfirewall allows System2's communication through. System1 can then respond to System2's communication and now both parties have established a network connection to one another from behind firewalls which are closed to unsolicited ingress traffic, sometimes known in the art as stateful firewalls. Both firewalls remained closed to unsolicited ingress traffic, and there was no underlying network reconfiguration required but both System1 and System2 are now able to exchange network traffic with one another. This is a technique known in the art as UDP or TCP hole punching (as it is frequently used with the UDP and TCP protocols) and can be performed in respect of UDP or TCP network traffic. In the event that the coordinated connection attempt at hole punching fails for some reason, the connection can alternatively be made via a relay service provided as a component of the Platform.
With reference now to step 3 of
With reference to
By way of example, suppose that Carol has registered with the Platform and therefore has an account and at least one Enrolment Key. Carol then:
Therefore, the disclosure provides an improved approach for capturing and exchanging the intent that two or more Systems need in order to connect with each other. Instead of the operator of PNL43 exchanging Certificate Names with operator(s) of GFS68 and LDT21 via an manual method, the DS provides the necessary information to the Systems because the DS has a stored record in the form of a Policy configuration that records Carol's intent to connect the systems. Therefore, the DS is pre-authorised to make the introductions between the Systems and provides them with the necessary Connection Candidates.
The Tags and Policies enable a many-to-many relationship, as a given System can be a member of more than one Tag, and thus will inherit the Policies (rules) of each Tag that it is associated with a given Policy. Carol is able to describe and define connectivity in her Account by applying Tags to the relevant systems and creating Policies composed of those Tags. This enables the construction of complex topologies but easy-to-configure connectivity topologies. Through the use of Tags and Policies, embodiments enable a transition from local i.e. device-level control of Tunnels to a centrally controlled approach i.e. at the Platform, defined by Carol or Platform Administrators.
Advantageously, Carol can push changes and reconfigurations down to multiple Systems across the Account in one simple, efficient and quick operation that is performed via the Web Portal. Also, there is no need to perform an in-person, out-of-band exchange of Certificate Names as disclosed in WO 2017/060675 because the information that is exchanged is provided by a Discovery Service in the form of a computer-implemented Policy shared by and associated with the Enrolled Systems. Thus, the exchange is performed machine-to-machine rather than manually and mutual intent is established using a pre-determined/pre-defined/stored set of Tags and Policies which provide a priori knowledge of which systems have a mutual intent to connect. This not only saves time, resources and processing effort but it provides a more secure exchange mechanism because it reduces the likelihood of interception by any unauthorised parties. It also means that out-of-band challenges such as time zone or language differences are avoided.
We now turn to an aspect of the disclosure with particular reference to
As readily known in the art, VPNs are an example of an overlay network. Overlay networks are built on top of the physical infrastructure of an underlay network, such as the Internet, which serves as the data transportation and packet routing mechanism. This physical infrastructure comprises devices such as servers, switches, firewalls and routers. See, for example, https://en.wikipedia.org/wiki/Overlay_network. Therefore, while the VPN provides a logical, abstracted layer of inter-system communications, the data packets are, in reality, encapsulated and carried by the underlay network, but usually in conjunction with encryption where the secret keys are not known to intermediary devices on the underlay network which therefore cannot decrypt the encapsulated packets they carry (hence the private in virtual private network). Devices on the underlay network route traffic between source and destination Systems via standard routing protocols and Internet connectivity (or other interchangeable medium), and packets are delivered based on the destination's IP address and subject to any configuration of the underlay network devices.
In the context of a traditional network, in order for hosts to communicate with IP packets, each IP address is mapped to an Ethernet address, known in the art as a MAC address, and the behaviour and resolution of MAC addresses into IP addresses is known as and described in RFC 826, An Ethernet Address Resolution Protocol (ARP). The role of ARP is to translate the IP address used by the underlay network into an Ethernet address that is compatible with operating systems running on devices within the LAN.
In a traditional network, when a system or device is added to a LAN, an IP address is allocated to it so that other devices can identify it and IP packets can be sent between that system and other systems on the network. IP packets are encapsulated and carried by Ethernet frames. Subsequently, when a source system wants to send an IP packet to a destination system on the LAN at a particular IP address, the source system's operating system (OS) needs to know the MAC address that corresponds to the destination's IP address. The OS (11) attempts to resolve this by querying a look-up table that it maintains, known as the ARP cache, which lists known IP addresses that it has previously encountered and their corresponding MAC addresses. If the OS finds an existing entry for the IP address in question, it retrieves the corresponding MAC address from the ARP cache and uses it in the construction of the data packet which is then placed onto the network to be routed to the specified destination. If no existing entry can be found, however, the OS broadcasts an ARP request to all systems in the LAN to ask if any of them are identified by that particular IP address. If a receiving system or device on the LAN recognises the IP address as its own, it responds to the query by providing its own MAC address. The OS (11) adds the responders MAC address to its ARP cache table for future reference, and the data packet is constructed and placed onto the network. Any future traffic that is to be sent to the same IP address will not require another ARP request, because the MAC address will be available to the OS from its ARP cache.
However, this design gives rise to a vulnerability known as “ARP cache poisoning” or “ARP spoofing”, in which a malicious third party intercepts an ARP request and responds with its own MAC address. This means that the attacker's MAC address will be added to the ARP cache entry for that IP address and subsequently used when constructing data packets intended for that IP address. As a result, the traffic is diverted to the attacker's machine and the attacker is able to read it, or use it for denial of service (DOS), man-in-the-middle or session hijacking attacks.
Within the context of the present disclosure, the Platform enables creation of a Tunnel which exists as a peer-to-peer overlay network, that may carry encapsulating Ethernet frames between connected Peers across the underlay network e.g. Internet. Therefore, when traffic is sent from System1 to System2, it has to be transported via the physical infrastructure of the underlay layer. However, the IP addresses and subnets of the overlay (VPN) are different from the IP addresses used at the underlay level. When an Agent running on System1 establishes a connection with an Agent running on System2, both Agents need to handle data that is being sent and received, in both directions. Existing applications (12) installed on each system, and also each system's OS (11), may send Ethernet frames directly to the local virtual network interface (TAP devices) created on the local system by the Platform. This is illustrated in
Recall from the above explanation that Systems enrolled with the Platform receive, from the DS, one or more potential Connection Candidates that they can use to reach other Enrolled Systems. System1 receives one or more potential Connection Candidates that its Agent can use to attempt to reach System2. The Connection Candidates comprise at least an IP addresses and port number that may be used to connect the systems. After connection, data flowing between the connected systems is sent directly from peer-to-peer using their respective IP addresses, and each Agent within the VPN knows the VPN IP addresses of other Peers which it is able to connect with.
As a result, the conventional meaning given to a MAC address (all connecting parties agree a common lookup table binding IP address to MAC address) may be discarded in the context of a peer-to-peer overlay network. An Operating System still requires an IP to Ethernet address binding, but Peers need not agree on the same binding. Recall, that data has to be physically transported over the underlay network which uses different IP addresses from the overlay. This means that traffic flowing between System1 and System2 still needs to conform to the required format expected by operating systems and devices at the underlay layer. In particular, data packets travelling between System1 and System2 still need to provide source and destination MAC addresses so as to satisfy the underlying communications protocol and OS requirements, even though MAC addresses are irrelevant for their purposes.
This challenge is addressed as follows. Suppose that the Agent on System1 has established connectivity with the Agent on System2 in accordance with an embodiment of the Platform described herein. System1 now wishes to send a data packet to System2. (We refer to this as the “inner, or encapsulated data packet”). As MAC addresses are meaningless at the overlay level, System1's Agent generates a spurious MAC address that can be used for the generation of the data packet that it wants to send to System2. This spurious address is a MAC address which appears to be genuine but is, in fact, false and is not the real MAC address for System2. It is, therefore a meaningless MAC address. The technique of using spurious MAC addresses may, therefore, be referred to herein as a “Fake ARP” technique. The spurious MAC address can be generated in any suitable way such as, for example, using a random or pseudo-random generation technique, or could be generated using a deterministic approach. Both the source and destination MAC addresses in the data packet may be spurious. In accordance with another form of wording, the spurious MAC address does not comprise data that enables identification of System2 on the network. Put yet another way, the spurious MAC address complies with communications protocol and OS requirements but cannot be used to actually locate the device (System2) or any other device on the relevant network. The meaningless MAC address satisfies formal protocol requirements but System1/System2 do not act upon or use it in terms of transmission of data, and therefore the fact that the MAC address is not genuine and does not identify a genuine device on the network does not give rise to any technical difficulties for System1/System2.
In a preferred embodiment, each Agent maintains its own record of spurious MAC addresses that it has generated for systems that are enrolled with the Platform and that it is able to connect with. Therefore, Agent1 may comprise, or have access to, a database or other repository of fake MAC addresses that it has associated with the IP addresses of Peers. Each time System1 wishes to send data to a given Peer, the Agent will use the same fake MAC address that it has generated and associated with that peer. The sending and receiving Agents do not need to agree on the MAC addresses that have been put into a data packet because they are irrelevant to them. If the Agent on system1 receives an inner data packet with a MAC address from System2 that does not match the entry in its fake ARP cache for System2, it can simply substitute it for its pre-stored fake MAC address before handing the packet to the OS because deliverability has already achieved (the two Peers have all the reachability information they need to send traffic between them). Consistency for the OS is achieved by ensuring that it always receives the same source MAC address for a given sender. As long as the MAC address meets the expected format, the OS has no way of discerning that it is a spurious address and accepts it as genuine. Therefore, it is irrelevant what the sender specifies as the source MAC address in the inner packet because the receiving system will exchange it for the fake address that it has chosen and associated with that sender.
After the fake MAC address has been provided in the “Source MAC address” field of the inner packet, Agent1 encrypts the inner packet and inserts it into the data section of a further data packet which we will refer to as the “outer data packet”.
In order to send this packet across the underlay network, though, System1 needs to know the source and destination MAC addresses for the two systems as these are required for completion of the data packet fields that the underlay will need to use. The OS at the receiving end will need to know the MAC addresses for the source and destination. While System1 knows its own MAC address it does not know System2's, so it sends an ARP request to a broadcast address as known in the prior art. In response, System1 receives a MAC address for System2. It uses the received MAC address to complete the field for the destination MAC address in the outer packet.
The outer data packet now contains all the necessary data to satisfy the underlay network's requirements, and it also includes the encrypted inner data packet as data. Agent1 then sends the outer data packet for transportation across the network to the destination specified in its IP address field, which is System2's IP address. At the receiving end, the Agent on System2 unpacks the outer data packet to access the inner data packet and decrypts it. It ignores the MAC address as it does not need it for deliverability purposes and sends the desired data to the specified IP address.
Thus, embodiments of the disclosure provide security advantages in that the threat of ARP cache poisoning is made irrelevant. In such attacks, an attacker would never substitute a real MAC address for a spurious one because this would defeat their goal of diverting traffic to their system. Therefore, the attacker substitutes their own MAC address for the intended one, their own address being a genuine MAC address associated with a network device, albeit unauthorised.
With reference to
We now explain the scenario of System1 sending data to System2 in more detail from the perspective of the Platform described above, and with reference to
We now explain the processing steps undertaken by the Fake ARP module on each pathway, without limitation, in accordance with a preferred embodiment, again with reference to
In some circumstances, the received packet may need to be modified in order for the Fake ARP module to function. For example if the received traffic is an IPv4 packet. As explained above, every Ethernet frame requires a MAC address. Usually, the sender is responsible for setting the MAC address of the Ethernet frame, but this gives rise to the potential for ARP cache poisoning attacks. Therefore, the fake ARP module performs two tasks: 1) it prevents ARP traffic from crossing the Tunnel between the two connected peers, but in doing so it also prevents them establishing a common understanding of each other's MAC addresses; 2) instead then, the Fake ARP module randomly generates a MAC address for each connected Peer and replaces the MAC address on any received packet with the locally generated MAC address for said Peer. By doing this, the sender is unable to influence the receiver's operating system ARP table.
In the disclosed solution, each peer has a unique virtual IP address, Peers communicate with each other primarily by sending packets to one another setting by the destination IP address to that of their connected Peer's virtual IP address. For example, System1 is 100.64.0.10 and System2 is 100.64.0.20. These IP addresses only have meaning when System1 and System2 are connected using the disclosed Platform. Without that connection, these IP addresses lose their meaning to each party. If the received packet is destined for the receiver's virtual IP address then in order to complete the MAC address manipulation of the packet we set the destination MAC address to be the receiver's (spurious) local generated MAC address. The sender could not have done this as it has no knowledge of the receiver's MAC address (because the Fake ARP module prevents ARP traffic from crossing the Tunnel).
With reference to
Non-ARP traffic received from the local Virtual Network Interface is anticipated to either be unicast or broadcast traffic and the module allows these packets to continue in the processing pipeline to be sent on to any connected peers assuming no other successive modules in the pipeline make a contrary decision.
This is the pathway the module takes when the local operating system attempts to find the MAC address for an IP address of a connected Peer by generating and attempting to send an ArpRequest across the Tunnel. The fake ARP module will not allow this packet to cross the Tunnel to reach any connected Peers. Instead, it will create a fake ArpReply packet locally and send it back to the operating system. To do this, the Agent records both the SenderHardwareAddress (i.e. a MAC address: 00:00:00:00:00:00) and SenderProtocolAddress (i.e. IP address: 0.0.0.0) from the ArpRequest packet and stores them in an in-memory database.
The operating system may attempt to direct traffic via default route. Therefore, the Fake ARP module generates a random MAC address and sets the first two bits of the first byte to indicate that this address is both locally administered, and configured for unicast traffic. This MAC address is then stored by the Agent and assigned to whichever IP address it selects as a fake default route.
If the ARP Request was directed at the LastUsableIP address of the Agent assigned subnet, then the Fake ARP module edits the Request packet, sets the SenderHardwareAddress to the pre-generated randomly selected MAC address for the fake default route and sets the SenderProtocolAddress to be the last usable IP address of the subnet. In this way, the module is effectively editing the Request Packet (rather than allocating a new data structure) to set the sender fields to appear to have originated from the original destination the packet targeted, but the destination does not actually exist. This is the reason for the Fake ARP module intervening to intercept the ARP request, modify the packet to look like a legitimate reply and send it back as an ARP response. In effect, the Fake ARP module fakes a reply from the relevant connected Peer.
In some cases, the ARP Request packet received may not be targeting a unicast destination IP address. In such cases, the Agent does not need to fake a response and the original packet may be discarded by the module without eliciting a fake ARP response back to the OS.
As already explained, the Fake ARP module re-writes the sender fields of the ARP Request packet so it can be sent back to the operating system purporting to be an authentic ARP reply to the original ARP request. On this path, the OS has attempted to ascertain the MAC address corresponding to a virtual IP address of a connected Peer. Each time a peer-to-peer connection is established between two Agents, each Agent generates a random MAC address to associate with its far-side Peer. When packets are sent to a far-side peer, the OS attempts to discover the MAC address for that Peer's virtual IP address by placing an ARP request onto the network. This flow alters the ARP Request packet to move the original sender information to the destination fields of the packet and populates the now empty sender information with the locally held information about the remote Peer (i.e. the spurious MAC address and virtual IP address). The operation field is also switched from Request to Response. Once the packet updates are completed, the Fake ARP module places it back onto the local Virtual Network Interface for the OS to collect and process as if the packet had really traversed a network, reached a remote Peer and elicited a response.
Thus, significant improvements and advantages are provided by the present disclosure compared with the prior art. In a traditional model, for example, the VPN acts as a router and all traffic passes through it. Therefore, the VPN server may police the traffic for fake or illegitimate ARP replies. Moreover, it is able to see it. If it encounters a MAC address that it suspects may be suspicious or malicious in nature, it may attempt to resolve the MAC address. Therefore, in the traditional architecture, ARP poisoning is typically addressed either on the VPN server or on network devices connecting systems together like network switches. By contrast, systems which are peers in embodiments of the disclosure generate false MAC addresses for themselves and every other peer they are connected to. As the VPN server is the overlay network's router in the traditional model, ARP cache poisoning may be a problem for prior art VPNs unless the VPN server comprises a solution to address it.
In accordance with embodiments, the enrolled Peer still comprises a switch that all traffic moves through but instead of it being a VPN server on the underlay network all traffic on the overlay is encrypted so none of the components of the underlay network can see it. Therefore, the underlay switch cannot see nor police the traffic.
As the underlay network takes care of the transportation, routing, and delivery of the data, by the time the data is received at the receiving system and is decrypted by its Agent, the part of the data transfer process which would typically require MAC addresses has already been performed. Therefore, the Agent is able to use spurious MAC addresses in the packets simply for compliance with required protocol formats. The Agent ensures that the MAC address for the source is consistent with historical events when it hands the packet back to the OS.
In summary, embodiments of the disclosure emulate a bridged LAN when running in OSI model “Layer 2” mode. No routing takes place on the virtual overlay network and, therefore, there is a need for protection against ARP cache poisoning. Embodiments may operate at either Layer 2 level (transporting Ethernet frames and associated payloads) or at Layer 3 (transporting IP packets and associated payloads). When in Layer 3 mode, ARP cache poisoning protections are not required as ARP traffic is carried by Ethernet frames, not IP packets. Therefore, ARP cache protection is not relevant in Layer 3 mode because ARP traffic itself cannot be exchanged between connected peers. However, some embodiments may comprise systems running on different operating systems. Some may operate at Layer 2 (e.g. Windows and Linux) while others (e.g. Mac OS) do not allow the creation of a Layer 2 virtual network interface, thus requiring connectivity at Layer 3. In such situations, System1 could be sending Ethernet frames while System2 could be sending IP packets. To address this, embodiments may comprise a “middle layer” that removes the Ethernet frame from anything System2 receives from System1, and in reverse adds an Ethernet frame header to the IP packets System1 receives from System2.
We now turn to another aspect of the disclosure, with particular reference to
When an application (12) on a client system needs to communicate with a host System across the network, the client sends a query to System2. A DNS at the host responds to the client's query and translates the human-friendly domain name in the query into a machine-understandable IP address (see https://en.wikipedia.org/wiki/Name_server). However, it clearly requires time and effort to send and receive information across the network. Therefore, to speed up this process, Operating Systems are designed to include a component called a “stub resolver” which creates and maintains a cached record of IP-address/domain name pairs that are already known to the client. Any DNS queries that cannot be solved by the stub resolver at the client side are sent out over the network for resolution by a specified name server (also known as a “recursive resolver”).
For illustration, consider a simple scenario where a browser on System1 wishes to access content from a web server (System2) having the domain name www.System2website.com. Instead of going directly to the web server over the Internet and asking for the necessary IP address, the browser asks its local OS for it first. System1's OS's stub resolver interrogates a look up table in its cache to see if it already has the required IP address for that domain name. If it does, it sends this back to the browser but, if it does not, it sends a query to the specified name server and obtains it from there.
However, the traditional DNS approach is notoriously complex, brittle and vulnerable to failure. In particular, DNS problems often stem from improper configuration of DNS records by human administrators, who can fail to enter the correct values and IP addresses into their systems' records. This poor configuration causes the DNS resolution process to fail and leads to unavailability of services and applications such as online content and system-to-system communications.
We now refer to a preferred, illustrative embodiment shown in
Recall that, as explained above, network reachability information is stored at the Platform for each System that has been enrolled. This reachability information includes IP addresses and port numbers, and provides a way for other Systems to determine the location on the network the System that a given Agent is installed on. The reachability information is refreshed each time the Agent (re) connects to the Platform (usually via the public Internet). Therefore, the network reachability information enables Agents installed on enrolled systems to locate and connect with each other following introduction via the Platform's Discovery Service. IP addresses for enrolled Systems are pre-stored and known at the Platform.
Suppose that System1's administrator (Carol) assigns the DNS name www.System1.com to Alice's web server (System1). (In other examples, the DNS name could be assigned to a zone or a subzone associated with System1). Sometime following this, Bob types the domain name www.System1.com into a web browser (12) on his laptop, System2 (7). The browser therefore knows the server's domain name but needs to know its IP address in order to reach it. Traditionally, the stub resolver (14) associated with the OS on System2 would acts as an intervening intermediary and provide the relevant IP address to the browser or, if that fails, contact a series of DNS Name Servers in order to obtain the necessary address. However, as System2 is enrolled with the Platform and is running an Agent in accordance with the present disclosure, it has a stub resolver associated with that Agent. In a preferred embodiment, this Agent-based resolver is provided in addition to the traditional OS stub resolver.
The Agent's stub resolver comprises a cache of DNS names and their associated IP addresses and is, therefore, able to look up the IP address associated with a given domain name. The Agent's stub resolver intercepts and responds to the browser's DNS query in the same way that the OS level stub-resolver would before it arrives at the OS resolver. If this fails, the DNS query will be resolved by reverting to OS-level stub resolver and/or the Internet as per the traditional approach described above. This removes the need for involvement of the public Internet for DNS-queries relating to enrolled Systems, and provides a secure, efficient and swift mechanism for resolving domain names within VPNs constructed in accordance with embodiments disclosed herein.
The approach is implemented via the use of tags. When Carol gives a domain name to a System, zone or sub-zone within the VPN she assigns, via the Platform's Portal, at least one Tag to that domain name. Effectively, this provides Carol with a mechanism for specifying which enrolled Systems are authorised to know the domain name. An enrolled System only becomes aware of a particular domain name if the Tags and Policies applied to the System specify that it is allowed to know it and is also allowed to know about the existence of the System that domain name is associated with.
It should be noted that multiple Tags can be assigned to one or more names. This is diametrically opposed to the traditional approach, in which a single System/IP address is assigned to a domain name. In this new approach, however, groups of enrolled Systems can be associated with a given name. Therefore, in contrast to the prior art, embodiments of the disclosure provide mechanisms for a multiplexed assignment or association of domain names and IP addresses.
Moreover, the Tag-based distribution mechanism means that the appropriate DNS for the mesh of the overlay network can be auto-computed. This ensures that any new name—to System assignments or updates are communicated to all enrolled Systems that are tagged as needing to know the IP address for a given domain name. Again, this provides advantages in terms of efficiency of time, effort and resources. Other benefits of the Agent-based approach to DNS include, but are not limited to:
The use of cryptographic techniques for securing and protecting sensitive data is well known. One such commonly used technique, known as asymmetric encryption, involves the use of a cryptographic key pair, in which the public key can be openly shared with other parties while its corresponding private key is retained as a secret by the key-pair owner. Ownership of the public key can be verified via the corresponding private key which is kept secret to the owner and used for encryption/decryption of data or the generation of digital signatures. However, challenges exist around how to distribute the public key between entities, given that third parties could intercept the transmission of the public key from Alice to Bob and by substituting Alice's public key for one of their own. When Bob uses that public key to encrypt messages and data, the interceptor is able to decrypt his message before passing it on to Alice, possibly in a changed state. Therefore, Bob needs to be sure that the public key he receives really is from Alice and he is not the target of a “man-in-the-middle” exploit.
‘Public Key Infrastructure’ (PKI) addresses this key distribution challenge through the issuance, management and use of digital certificates that enable verification of the identities of devices, applications, users and other entities. (See https://en.wikipedia.org/wiki/Public_key_infrastructure). A digital certificate is issued by a trusted source called a Certificate Authority (CA). Each CA has its own public-private key pair and, after performing verification checks on the holder's identity, signs the certificate to indicate that the CA has confirmed the identity. Analogous to a passport or driving licence that has been issued by a governmental authority, the CA's digital certificate can be inspected by anyone that wishes to verify a particular entity's identity. They can confirm that the certificate has come from the CA because it has been signed using the CA's private key and they have the assurance that the CA has performed its own identity checks before issuing the certificate.
In use, when a new digital certificate is required for a System such as a web server, a human operator e.g. an administrator such as Carol, manually generates a certificate signing request (CSR) and sends it with a monetary fee to a CA. The CA requests data that can be used to confirm the identity of the CSR's sender. After receiving and checking this data, and if the CA is able to establish the legitimacy of the CSR sender's identity, a digital certificate is provided for the entity identified in the CSR e.g. Carol's web server. This certificate issuance process can be summarised as:
It is worth noting that each CA has its own public-private key pair and certificate. This enables the generation of chains or hierarchies of CAs, in which CAs issue certificates for one another. However, a CA's digital certificate can always be traced back to a self-signed root CA. In respect of web browsers, a certificate received from a web server is accepted as valid by a client device because the root CA in the chain is pre-installed on the system by the operating system (OS) provider. However, it is recognised in the field that that this poses security risks. See https://www.keyfactor.com/resources/what-is-pki/:
Therefore, it is readily apparent that traditional approaches to PKI have some inherent downsides. These include but are not limited to: the need to trust an external CA, the need to provide identifying credentials to the CA for each CSR; the need for the CA to verify the credentials; the need for human, manual intervention in the CSR generation and checking steps; the need to pay the CA for its services; and the time and resources required to perform these steps.
In accordance with embodiments of the disclosure, the traditional PKI process can be automated due at least in part to the DNS mechanism described above. In the overlay network disclosed herein, when a new record (DNS name) is created and assigned to a System not only is that System itself informed of the name but all other Systems that are connected to it via its associated Tags and Policies also become aware of it. So, knowledge of the assignment of that name to a particular enrolled System (endpoint) propagates through to other enrolled Systems because of their authorisation to connect with it in the overlay network.
Consider, by way of example, a web server running on an enrolled System. Although is possible for other Systems to locate and connect with the web server, the web server needs a certificate so that browsers on the other systems will be able to verify its identity. Due to the Tags and Policies mechanisms disclosed herein, the System can automatically generate the CSR and send it to the Platform's private CA that is only recognised by the Agents on the Systems in the overlay network.
Advantages of this include:
Therefore, creating the new DNS record triggers multiple events and actions. Recall that in the prior art, in order for certificates to be trusted by a given System the CA has to be pre-installed at
OS level by the OS provider. Embodiments of the disclosure emulate this same functionality on enrolled Systems via the Platform's CA. In effect, there is a provided a mechanism for distributing the public certificate from the CA and installing it on every System that might need to trust its certificate.
The steps of a preferred embodiment may comprise:
Importantly, in the traditional approach the actions taken by the Agent are all user initiated. The human administrator chooses, generates and manages the events. By contrast, in accordance with embodiments of the disclosure, the actions are machine initiated and executed. The Platform tells the Agent what DNS name it is to use. Moreover, the Platform issues the CSR over the overlay network via a closed communication channel, which provides the advantage of enhanced security because opportunities for eavesdropping or interception by unauthorised third parties are minimised. Further still, embodiments enable generation of the certificate from a root certificate that is specific to a given organisation. This means that each organisation is able to have its own root certificate, rather than the root certificate belonging to a Certificate Authority that is external to the Platform and has to be trusted with secure storage of its own private keys, as mentioned above.
Therefore, in direct contrast to the prior art, embodiments provide methods and systems for pre-authenticated DNS and CSR. This is possible because the overlay network described herein enables a mechanism that allows a System to provably verify, in a CSR, that it is who it says it is. In effect, the private CA already knows the System's identity. In the traditional DNS process/CSR, there is no concept of pre-authenticated proof of identity because the CA is a trusted, third party that is external to the organisation that the System belongs to. Therefore, the invention provides a significantly different approach involving different actions performed by different parties having different roles. The digital certificate ends up in the correct location place but without all the resources and intervention required by traditional approach.
Embodiments claimed and disclosed herein may utilise or comprise methods or systems substantially as described in PCT/IB2022/053460, the contents of which are incorporated herein in their entirety.
The disclosure also provides various methods as described, claimed and illustrated herein. It also provides computer-based systems (which may be referred to as networks, apparatus and/or equipment) for implementation of any method disclosed herein. The apparatus may comprise hardware, software and/or firmware. Software/firmware provided in association with the hardware may be arranged to perform, upon execution, one or more of the method steps disclosed herein.
The enumerated clause sets and aspects provided below are not intended to be limiting, and feature(s) from one clause set/aspect may be incorporated into one or more other clause sets/aspects.
According to a first aspect or wording of the disclosure, preferred embodiments may be provided as described in the following enumerated clauses:
Clause 1) A computer-implemented method for establishing or facilitating connectivity between a first system (6) and a second system (7).
The first and second systems may each be:
The method may comprise:
The permission/intention may be provided by an authorised or controlling party e.g. administrator or Account Owner. The permission/intention may comprise at least one tag as described herein. The first and/or second systems may be computer-based resources, comprising one or more electronic or virtual devices. The introduction may be performed by a discovery service provided by or associated with the computer-based Platform.
Embodiments of the disclosure may provide methods and apparatus for facilitating, or enabling the provision or emulation of a virtual network adapter at respective ends of a communication channel. It may also be referred to as a solution for providing a computer-based overlay network on top of an underlay network. It may be implemented as a software-based agent that is downloaded and installed on each system that is to be connectable and/or managed via the platform. The platform can be cloud-based, distributed and/or SaaS-based.
The method may comprise downloading and/or installing an Agent (client) substantially as described herein on the first or second system(s).
2) A computer-implemented method according to Clause 1, wherein the permission/intention to connect:
The permission and/or intention to connect may be stored at the Platform on a per-account basis.
3) A computer-implemented method according to Clause 1 or 2; wherein
The Enrolment Key may be associated at the Platform with the arbitrary identifier; and/or generated by the Platform during an enrolment or on-boarding or joining process performed by the first system.
4) A method according to any preceding Clause and comprising the step:
5) A method according to Clause 4 wherein the tag:
6) A method according to Clause 4 or 5 and further comprising the step of
7) A method according to any preceding Clause and comprising the step of:
The certificate name may also be known as an arbitrary identifier.
8) A method according to any preceding Clause wherein the Platform:
The portal may also be referred to as an (administrator) control interface and may be arranged to provide facilitate or enable an administrator, controller, network controller or other authorized entity to control an account at the Platform, specify settings for the account, enroll or remove systems at the Platform and/or specify one or more Tags or Policies as described herein.
9) A computer-implemented method for establishing or facilitating connectivity between a first system and a second system, wherein each system:
Respective i.e. different enrolment keys are provided by the platform for each of the first and second systems; Connection candidates may be sent to the first system to enable it to attempt to connect to the second system; and/or Connection candidates may be sent to the second system to enable it to attempt to connect to the first system. The Connection Candidates may be sent from a discovery service provided by or associated with the computer-based Platform.
10. A method according to Clause 9, and comprising the step:
11. A method according to Clause 9 or 10, wherein:
12. A computer-implemented method for establishing or facilitating connectivity between a first system and a second system, wherein each system:
13. A method according to Clause 12 wherein:
14.A method according to Clause 13 wherein the certificate name:
15.A method according to Clause 13 or 14 and comprising the step of:
16. A method according to any of Clauses 13 to 15 and further comprising the step of generating the arbitrary identifier using:
17.A method according to any of Clauses 13 to 16 and further comprising the step of:
18 A method according to any of Clauses 13 to 17 wherein the cryptographic key is a public key and the first system provides an indication of knowledge of the private key associated with the public key, and wherein the indication of knowledge is provided to:
19. A method according to any of Clauses 13 to 18 wherein the method comprises the steps of:
20. A computer system comprising computer equipment, the equipment comprising:
21. A system according to Clause 20 wherein the system comprises:
22. A system according to Clause 20 or 21 wherein the system also comprises:
23. A system according to any of Clauses 20 to 22 wherein the system is arranged or operative to: generate and/or provide an Enrolment Key to the first and/or second system;
24. A system according to Clauses 20 to 23 wherein the certificate authority is arranged and configured to:
25. A system according to Clauses 20 to 24 wherein the discovery service component is arranged and configured to
26. A computer program embodied on computer-readable storage and configured so as, when run on one or more processors, to perform the method of any of preceding clause(s) or embodiments described herein.
Preferably, embodiments of the disclosure may comprise a Platform that is arranged for communication with a software Agent. The Agent may be arranged for download, installation and/or execution on a computer-based resource (that we may call a ‘System’) to enable the system to use and/or communicate with the Platform, and/or vice versa. Thus, systems and apparatus disclosed herein may comprise an agent substantially as disclosed herein, and methods of the disclosure may comprise the step of accessing, downloading, installing, executing and/or using an Agent to/on a computer-based resource (System).
According to another aspect of the disclosure, preferred embodiments may be provided as described in the following enumerated clauses. Any feature recited in the clauses of this aspect may be relevant and applicable to any clause(s) of any other aspect and vice versa. These aspects are not intended to be mutually exclusive, and features from one aspect may be incorporated into any other. Embodiments recited in respect of this present aspect may relate substantially (but not exclusively) to the section of the description relating to “Fake ARP” and with particular reference to
Clause 2.1. A computer-implemented method comprising:
Clause 2.2. A method according to clause 2.1, wherein:
Clause 2.3. A method according to clause 2.1 or 2.2, wherein:
Clause 2.4. A method according to any preceding clause, wherein:
Clause 2.5. A method according to any preceding clause of the second aspect, wherein:
Clause 2.6. A method according to any preceding clause of the second aspect, wherein:
Clause 2.7. A method according to clause 2.6, wherein:
Clause 2.8. A method according to any preceding clause of the second aspect, wherein the first and second systems are each:
Clause 2.9. A method according to any of clauses 2.1 to 2.7, wherein the first and second systems are each:
Clause 2.10. A method according to clause 2.9, and comprising the step:
Clause 2.11. A method according to any of clauses 2.1 to 2.7, wherein the first and second systems are each:
Clause 2.12. A method according to any of clauses 2.8 to 2.11 wherein the Platform:
Clause 2.13. A computer-implemented system comprising:
Clause 2.14. A computer-implemented system comprising:
Clause 2.15. A system according to clause 2.14 and further comprising:
Clause 2.16. A system according to any of clauses 2.14 or 2.15 wherein the system is operative to:
Clause 2.17. A system according to clauses 2.15 or 2.16 wherein the certificate authority is operative to:
Clause 2.18. A system according to clauses 2.15 to 2.17 wherein the discovery service component is arranged and configured to
In accordance with another aspect or wording of the disclosure, there may be provided methods and corresponding systems substantially as described herein in respect of the “novel DNS” solution.
In accordance with one form of wording, an embodiment may comprise an agent-based stub resolver. Preferably, the stub resolver is provided in association with, or as part of, an Agent that is installed on a computer-based resource (System) that is enrolled with a Platform substantially as described herein. The embodiment may comprise the step of using a Tag (that an administrator (Carol) may have applied to the System) to associate a domain name with an IP address, and/or to resolve a domain name for the enrolled System to an IP address.
A preferred embodiment may comprise one or more of the following steps:
Preferably, the Agent's stub resolver comprises a list/record/cache of one or more names. The one or more names may comprise or be DNS names. Each DNS name in the list may be associated with a respective IP address. Thus, the stub resolver may be operative to determine the IP address associated with a given domain name. Preferably, the Agent's stub resolver is operative to intercept and respond to a browser's DNS query before it arrives at the stub resolver of the operating system of the computer-based resource (System). Preferably, the method may comprise the step of reverting or passing the query to the operating system's stub resolver and/or the Internet if the stub resolver is unable to resolve the browser's DNS query.
Additionally, or alternatively, in accordance with this aspect of the disclosure, there may be provided a computer-implemented method and corresponding system for establishing or facilitating connectivity between a plurality of systems over an overlay network, wherein each system in the plurality is registered with a computer-based platform; the method comprising:
Additionally, or alternatively, there may be provided a computer-implemented method for establishing or facilitating connectivity between a plurality of systems over an overlay network substantially as described herein, wherein each system in the plurality is registered with a computer-based platform; the method comprising:
The method may further comprise at least one of the following steps:
Preferably, the stub resolver:
The method may comprise one or more of the following step(s):
The alternative forms of wording provided in respect of this aspect of the disclosure are not intended to be limiting. Thus, feature(s) from any one form of wording may be incorporated into another of the provided forms of wording, and features from alternative wordings may be combined to define possible embodiments of the disclosure.
In accordance with another aspect or wording of the disclosure, there may be provided methods and systems substantially as described herein in respect of the “novel managed PKI” solution. There may be provided a computer-implemented method for establishing or facilitating connectivity between a plurality of systems over an overlay network. Additionally or alternatively, there may be provided a method and corresponding systems for providing a pre-authenticating certificate signing request (CSR). This may be performed over an overlay network. The overlay network may be established in accordance with an embodiment of any aspect of the disclosure set out herein.
In accordance with one form of wording, a method may be provided comprising one or more of the following steps:
In accordance with an additional or alternative form of wording, there may be provided illustrative embodiments as set out in the following clause set. Features and steps from the wording above may be incorporated into any of the following clauses and vice versa.
Clause 1. A computer-implemented method of providing a digital certificate and/or a digital certificate signing request (CSR), comprising the steps:
Clause 2. A method according to clause 1 and further comprising at least one of the steps of:
Clause 3. A method according to clause 1 or 2, and further comprising at least one of:
Clause 4. A method according to any preceding clause, and comprising one or more of:
Clause 5. A method according to any preceding clause, wherein
It should be noted that the above-mentioned embodiments illustrate rather than limit the disclosure, and that those skilled in the art will be capable of designing many alternative embodiments without departing from the scope of the disclosure as defined by the appended claims. In the claims, any reference signs placed in parentheses shall not be construed as limiting the claims. The word “comprising” and “comprises”, and the like, does not exclude the presence of elements or steps other than those listed in any claim or the specification as a whole. In the present specification, “comprises” means “includes or consists of” and “comprising” means “including or consisting of”. Throughout this specification the word “comprise”, or variations such as “includes”, “comprises” or “comprising”, will be understood to imply the inclusion of a stated element, integer or step, or group of elements, integers or steps, but not the exclusion of any other element, integer or step, or group of elements, integers or steps. The singular reference of an element does not exclude the plural reference of such elements and vice-versa. The disclosure may be implemented by means of hardware comprising several distinct elements, and by means of a suitably programmed computer. In a device claim enumerating several means, several of these means may be embodied by one and the same item of hardware. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.
| Number | Date | Country | Kind |
|---|---|---|---|
| 2205485.2 | Apr 2022 | GB | national |
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/IB2023/053581 | 4/7/2023 | WO |
