Patent Application
20180167355
Modern packet communications networks provide the infrastructure for an increasing number and variety of services. Such state-of-the-art internet and intranet infrastructure is able to connect a client-device with any of a vast number of correspondent devices (including server devices and peer client-devices).
The end-to-end communications path between corresponding terminal devices typically passes through a number of intermediate network devices. Network devices, both terminal- and intermediate-, may be referred to as “network nodes” or just as “nodes”.
Typical packet communications networks require that terminal devices be provisioned with routable network addresses to facilitate the identification of the terminal device and determination of a network path for the transmission of data packets. Popular addressing mechanisms include Ethernet and internet protocol (IPv4 and IPv6) addressing.
Routable Internet protocol addresses are assigned by hierarchical organizations in blocks (subnets) each containing a range of addresses. These subnets are assigned to devices in close proximity to each other. Proximity is in terms of network path distance, administrative domain, and geographic location. Network routing is facilitated by maintaining the assignment of addresses to devices in a manner that is relatively stable over time. These factors make it feasible for observers of network traffic to attribute features like identity, geographic and organizational location, and behavior over time to terminal devices.
Both legal and illegal interception devices are commonly deployed in networks to inspect, analyze, store, and act on data communications packets. In the case that the payload of a packet is in plain-text, deep packet inspection (DPI) methods are used to extract and analyze transmitted data. Increasingly however the payload of transmitted packets is encrypted, leaving just the source and destination IP addresses to identify the corresponding parties. Even this meta-data reveals much about the activities, interests, and attitudes of network users.
Methods to disguise IP addresses are known practices. Network address translation (NAT) is commonly used by intranet gateways to hide private intranet addresses and conserve limited IPv4 address space. Onion routing and networks of co-operating routers, such as the Tor network for example, are used to disguise the identity of correspondents by encapsulate messages in layers of encryption.
Current practice to authenticate and authorize access to online content and services relies on presentation of credentials (such as user-names, passwords and one-time tokens). Credentials are presented explicitly by the user—or on behalf of the user—by a password manager or single-sign-on service provider. It is a goal to have the convenience of single-sign-on mechanisms, but with significantly better efficiency and less complexity of setup and operation than present methods.
The present disclosure details the construction of a novel intermediate device—referred herein as “gateway-device”. The term “client-device” refers to a terminal device that an individual user employs to gain access to network services via the gateway-device. Examples include personal computers, tablets, smart phones, and similar consumer and custom devices.
Examples herein are described in terms of the internet protocol (IP), but they also apply to other similar network addressing mechanisms.
The present disclosure presents systems and methods to overcome the shortcomings of present methods used to control the visibility of identity and related information available to service providers and interceptors. To this end, systems and methods for users operating a client-device to select routable IP addresses with appropriate identity attribution, traceability, and information associated with an identity is provided herein. In the case that more than one address is selected, they are made available for concurrent use. This provides an improvement on existing virtual private network (VPN) and other such products that allocate just one routable address for use at any one time.
In a first aspect of the invention, a network address assignment system is described, comprising: a client-device address allocation system residing on a client-device, the client-device address allocation system comprising: a client-device application processor module, a client-device communications processor module, and a client-device persistent memory module; and a gateway-device address allocation system residing on a gateway-device, the gateway-device address allocation system comprising: a gateway-device application processor module, a gateway-device communications processor module, and a gateway-device persistent memory module, wherein the client-device address allocation system is configured to allocate network addresses to be used by the gateway-device for network traffic to and from the client-device.
One skilled in the art can envision further aspects given the disclosure herein.
An exemplary top-level structure of the system, consisting of client-device and gateway-device apparatus, and its operating environment is illustrated in
A user (100) operates a client-device (110). The interaction can be authenticated (105) such that any unauthorized user is not permitted to operate the client-device. Authenticated interaction means include: biometric assisted methods such as fingerprint, voice print, iris pattern recognition and so on; token based methods including RFID tokens, token generating devices, printed cards with one-time tokens, and similar methods.
The client-device (110) communicates with a personal gateway device (120) via an access address (130). This communication link can be secured by means of secure sockets layer (SSL), IPSec, or other public or private key encrypted protocol. The access address (130) can be a single public static address or it may be an address that changes over time to make tracking of the user more difficult. The access address can be shared by multiple users, as illustrated in
The client-device (110) actively notifies the gateway (120) whenever the client-device (110) acquires a new (temporary) address, enabling the gateway (120) to reach the client-device (110) whenever it has data packets to forward to it. The payload of each packet exchanged by the client-device (110) and gateway (120) can be encrypted, salted, and/or digitally signed to maintain integrity and privacy.
The personal gateway (120) routes data packets from the access address (130) to one of a number of external addresses (140-1, 140-2, . . . , 140-N), as well as in the reverse direction. The gateway (120) may consist of a single device or a network of devices connected by a secure packet communication means. Secured packet communication means include secure sockets layer (SSL), IPSec, or other public or private key encrypted protocol. Thus, the routing function may be carried out within a single device that presents a number of external addresses or it may be carried out within a network of devices, such as a network cloud service.
It is instructive to view the client-device (110) and gateway-device (120) as a single composite virtual device that presents a number of external addresses (140-1, 140-2, . . . , 140-N) through which it provides access to various online network services (160-1, 160-2, . . . , 160-N) and any desired network facilities, such as a domain name service DNS (170). Typically the gateway-device (120) has a static location within the packet network infrastructure (e.g. a server), while the client-device is mobile (e.g. a smart phone or wi-fi device). In this sense, an external service does not need to track the mobile device, but rather communicates via a static address provided by the gateway.
The external addresses (140-1, 140-2, . . . , 140-N) can each possess a number of special characteristics, such as the following:
Making reference to the above attributes, the external addresses (140-1, 140-2, . . . , 140-N) can also be categorized. The following are examples of such categories:
Suppose that one user (200) has established a verified and personality address with the system, and the other user (201) only has a verified address established. Then the first user (200) would have their traffic routed by a verified address (241) and a personality address (261). The second user would only have a verified address (242) usable for non-anonymous (or semi-anonymous, if the personality is an anonymous pseudonym) routing. Both users (200, 201) can also access a shared pool of anonymous addresses (251, 252, . . . , etc.) for anonymous access to the network (270).
Even individual-user-only systems can employ a shared pool of anonymous external addresses for that user, to allow greater anonymity in addressing.
The functional structure to realize the communication data flow of the invention is shown in
The set of external interfaces (390-1, 390-2, . . . , 390-M) for the gateway-device (301) are reflected on a client-device (300) as virtual network interfaces (340-1, 340-2, . . . , 340-M).
Each application is provided a filtered set of available virtual network interfaces. The filtering is performed by the Network Interface Context (330). An available external interface is selected by the user of the client-device (300) by means of an interface (310). Any non-selected virtual network interfaces can be hidden and made not available for use by the application. The Network Interface Context (330) can select the appropriate external interface address type to use on a case-by-case basis based on pre-set rules or user selection, or the application can be built to make the selection based on its own set of rules (for example, a credit card application selecting a verified personal address).
Alternatively, client-device applications may be provided with an application programming interface (API) or other suitable means to access more than one virtual network interface and hence utilize multiple external interfaces at the same time.
The one-to-one link between client side virtual network interfaces (340-1 et al.) and gateway side external interfaces (390-1 et al.) can be provided by a multiplex/demultiplex structure (350 and 380). The two MUX/DEMUX blocks (350 and 380) exchange network packets annotated with the identity of the selected external network interface (e.g. 390-1). The annotation may be achieved by an encapsulation (tunneling) protocol or by marking packet header fields or payload. For example, an IPv6 extension header containing an index of the selected external interface may be used to identify the desired interface.
The protocol used to multiplex traffic between a client-device and gateway-device can encrypt the annotation and any plain-text data. The protocol can also authenticate both ends of the connection and can include salted time-stamps, or other such mutually agreed mechanism, to protect against man-in-the-middle replay and denial-of-service attacks. Multiple options for such protocols are available, including tunneling protocols, such as secure shell (SSH) tunneling and IPSec, for example.
Abstracting the communications functions described above as a client-communications-processor (430) and a gateway-communications-processor (480) is shown in the example of
Both the client- and gateway-devices can incorporate a secure element (432 and 482) that contains a private key and associated decryption logic to enable the mutual authentication of the client-device (400) and gateway-device (401). Secure communications with external entities via the external network address (490) may employ either of these secure elements as follows:
Optionally, as illustrated in
Applications execute on either the client or gateway application processor individually, or as a composite application that has co-operating components on both processors. If the application is to be accessed by outside services, such as a user setting up a blog to be read by other, external, users, the blog application can be established on the gateway-device.
Each application can have a corresponding user interface (610-1 and 610-2) as part of the general client-device user interface (610). Also shown in
Table 1 shows a typical application that executes primarily on the gateway application processor, according to the specification in “Gateway Information Service Database”, and employs a client application processor for user interaction. The application is an instance of the same two component structure of the second application (632-2 and 682-2) as shown in
The illustrative example in Table 1 employs an external network interface associated with an individual person named “Charles Dodgson”, as published by a domain name service (DNS) record shown in Table 2.
In the example, Charles wants to provide a delivery service, having a source DNS address at “go.acme.com”, access to his real-world street address so that they can deliver a package to him. The Service Database can be set up to let delivery service, and only the delivery service, look up his street address by pinging Charles' DNS listed address, and only during a certain window of time. The Object Data provided for the IP address (address1) is Charles Dodgson's street address, at 1 Baker Street. The Access Data provides a log that the street address was “read” by service “go.acme.com” at the provided timestamp date and time. The service “go.acme.com” has, as provided in the Deonitic Data, an 8 hour window to access the street address after the timestamp provided in that entry (i.e. from 12:37 on Jul. 2, 2017). The Meta Data sets date when the Object Data is no longer valid (“valid-end”, on Aug. 23, 2017).
Table 3 shows a typical application that executes primarily on the gateway application processor, according to the specification in “Gateway Information Service Database”, and employs a client application processor for user interaction. The application is an instance of the same two component structure of the second application (632-2 and 682-2) as shown in
The illustrative example in Table 3 employs an external network interface associated with an organization named “MegaPix”, as published by a domain name service (DNS) record shown in Table 2.
In the example, MegaPix wants to provide everyone (designated with the wildcard <any> in this example), access to their real-world phone number so that they can call in for a two-day contest. The Service Database can be set up to let anyone look up their phone number by pinging MegaPix's DNS listed address, but only during a certain window of time. The Object Data provided for the IP address (address2) is MegaPix's call-in number, 1-800-555-1212. The Access Data provides a log that the phone number was “read” by service “hostserv.org” at the provided timestamp date and time. The people wanted to call in have, as provided in the Deonitic Data, a 2 day (48 hour) window to access the phone number after the timestamp provided in that entry (i.e. from Jun. 1, 2017 at 12:37). The Meta Data sets date when the Object Data is no longer valid (“valid-end”, on Jun. 21, 2017).
Other forms of Object Data can be used, with other permissions and logs being imagined, as needed by the user.
The aforementioned sample application responds to HTTPS requests addressed to the external network interface. A gateway information service database is constructed to specify what information is returned in response to which URL. Preferably this database also specifies the meta-data aspect, such as period of validity, of the information. Preferably the database also specifies the deontic aspect, such as who is able to access or modify the data. Preferably the information service also maintains records of access attempts of the data for analysis, non-repudiation and such purposes.
The global Internet is in a transition from an earlier version of the internet protocol (IPv4) to a more recent version (IPv6). The present invention is deployed to take advantage of the increased availability of IPv6 addresses compared to the shortage of IPv4 addresses.
This embodiment provides a user with multiple static IP addresses. One of the addresses is published by DNS, and is verifiable using a certificate available via an information service and a private key retained by a gateway secure element, as illustrated in
The gateway-device is typically embodied as a rack server maintained in a secure data center located as part of the Internet backbone infrastructure. The client-device is constructed as an enhancement of a mobile terminal device, typically a smartphone, tablet or laptop form-factor. The communication path between the client and gateway devices is implemented as a secure tunnel using a selectable tunneling protocol, including IPSec and OpenVPN.
Both the client application processor (610) and gateway application processor (660) are node.js Javascript/ECMSscript runtimes. Persistent storage is provided by the node.js file-system API. The nodejs network communications API is extended to include an external interface selector function. The client and gateway components are inter-connected by means of the node.js child process APIs. A number of embodiments of the disclosure have been described. Nevertheless, it will be understood that various modifications may be made without departing from the spirit and scope of the present disclosure. Accordingly, other embodiments are within the scope of the following claims.
The user interaction aspect of the system is illustrated in
The user is provided with an interaction means, such as shown in
The user is also provided with a means to create, modify and delete an external address. A graphical interface means to achieve this is illustrated in
As a further aspect of the invention, the user can select services to be associated with a chosen external address. As an example, illustrated in
The examples set forth above are provided to those of ordinary skill in the art as a complete disclosure and description of how to make and use the embodiments of the disclosure, and are not intended to limit the scope of what the inventor/inventors regard as their disclosure.
Modifications of the above-described modes for carrying out the methods and systems herein disclosed that are obvious to persons of skill in the art are intended to be within the scope of the following claims. All patents and publications mentioned in the specification are indicative of the levels of skill of those skilled in the art to which the disclosure pertains. All references cited in this disclosure are incorporated by reference to the same extent as if each reference had been incorporated by reference in its entirety individually.
It is to be understood that the disclosure is not limited to particular methods or systems, which can, of course, vary. It is also to be understood that the terminology used herein is for the purpose of describing particular embodiments only, and is not intended to be limiting. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” include plural referents unless the content clearly dictates otherwise. The term “plurality” includes two or more referents unless the content clearly dictates otherwise. Unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which the disclosure pertains.
