ENHANCED PRIVACY-PRESERVING ACCESS TO A VPN SERVICE

Abstract

Systems and methods for effectively managing security and privacy measures during a user's connectivity session with a VPN service are provided. The systems and methods use a computer program that introduces a double-NAT feature at the network layer and a temporary hash table containing the minimally necessary temporary data to link two NAT sessions together in a secure manner. The systems and methods avoid including the dynamic management of IP addresses or requiring each client to have an IP address assigned beforehand to avoid compromising the user's identity by hard linking the session traces with the client

Claims

1. A computer-implemented method of allowing user access to a Virtual Private Network (VPN) service, the method comprising: receiving, at a VPN Concentrator (VC), a VPN tunnel establishment request from a user; receiving, from the user, an Identifier at the VC; verifying the Identifier at an Authentication Platform (AP) and providing, by the AP, access authorization consent to the user through the VC; establishing a VPN tunnel between the user and the VC, wherein an encapsulating layer of the tunnel is between a First Public Internet Protocol (IP) address of the user and a Second Public IP address of the VC, whereas a First Private IP address and a Second Private IP address are identical across at least two disparate VPN users' tunnels to the same VC, wherein the at least two disparate VPN users' tunnels to the same VC are simultaneous for at least some time, with both the First Private IP address and the Second Private IP address being associated with a First Private network; assigning, to the established VPN tunnel, a Third Private IP address that is associated with a Second Private network; registering, at the VC, packet descriptors including at least the Identifier and the Third Private IP address within a Peer Hashtable; receiving, from the user, a connection request to a Target on the Internet through the VC; altering, at the VC, a source IP address of packets, arriving from the user and leaving the First Private network, to the Third Private IP address; altering the source IP address of the packets, leaving the Second Private Network to a destination on the Internet, to a Third Public IP address; receiving the packets returning from the Target, at the VC's Third Public IP address and converting the destination address of the packets to the Third Private IP address; resolving the tunnel from the Peer Hashtable using the Third Private IP address; altering the destination address back to the second Private Address; and sending the packet back to the user via the VPN tunnel.

2. The method according to claim 1 wherein: the user packets destined to the external Target have the Third Private IP address, unique across the VPN tunnels at the singular VC, assigned to the packets as the source address; the user packets are submittable to a second NAT; the user packets are passed to a Internet-facing interface of the VC for further travelling to the target; and the user packets' source address leaving the VC are rewritten to the third public IP address of a designated VC interface.

3. The method according to claim 1, wherein the respective private IP addresses of the user and the VC are pre-configured and explicitly specified in local configuration files.

4. The method according to claim 1 wherein multiple VPN users have the same second Private address configured as each users private address for establishing VPN connectivity.

5. The method according to claim 1 wherein at least the Third Private IP address and the Identifier associated with a single users VPN session packets are stored in the Peer Hashtable and are retrieved for identifying the VPN tunnel corresponding to the user, wherein the packets returning from the Target are routed into the VPN tunnel identified.

6. The method according to claim 1 wherein the user's authentication is first submitted to a front-end AP system and at the front-end AP is subsequently submitted for further processing by a back-end AP component.

7. The method according to claim 1 wherein a standard Advanced Encryption Standard (AES) is used.

8. The method according to claim 1 wherein, the user with the AP is authenticated via the VC through a VPN application deployed locally at a user computing device.

9. The method according to claim 1 wherein, upon successful proof of a legitimate VPN user identity to the AP, a first access authorization for the user to access VPN service is received via the VC and the user's Public Key is provided to the VC.

10. The method according to claim 1, wherein the AP receives the user's access credential and evaluates if the user is a legitimate VPN service user by comparing the credentials provided with a user database record.

11. The method according to claim 10, wherein the VPN tunnel is established upon determining that the request is from a legitimate VPN service user.

12. The method according to claim 1, wherein the descriptors of the session that the packets of a particular user belong to, within the Peer Hashtable, includes at least the Third Private IP address, a Public Key of the corresponding user, and an Index value, produced during a handshake phase of the VPN tunnel establishment.

13. The method according to claim 1, wherein the descriptors of the session that the packets of a particular user belong to, are split into at least two Peer Hashtables, of which one comprises descriptors for an initial handshake, including at least the user's Public Key PubKey_1, and the other comprises descriptors for the established VPN connection, including at least an Index value within the packets.

14. A system for allowing user access to a Virtual Private Network (VPN) service, the system comprising: a VPN Concentrator (VC) operable to receive a VPN tunnel establishment request from a user, wherein the VC comprises a non-transitory computer readable medium; an Authentication Platform (AP) operable to receive an Identifier from the user, to verify the Identifier, and to provide access authorization consent to the user through the VC; wherein the VC is further operable to establish a VPN tunnel between the user and the VC, wherein an encapsulating layer of the tunnel is between a First Public Internet Protocol (IP) address of the user and a Second Public IP address of the VC, whereas a First Private IP address and a Second Private IP address are identical across at least two disparate VPN users' tunnels to the same VC, wherein the at least two disparate VPN users' tunnels to the same VC are simultaneous for at least some time, with both the First Private IP address and the Second Private IP address being associated with a First Private network; wherein the VC is further operable to assign, to the established VPN tunnel, a Third Private IP address that is associated with a Second Private network, register packet descriptors including at least the Identifier and the Third Private IP address within a Peer Hashtable, receive a connection request from the user to a Target on the Internet through the VC, alter a source IP address of packets, arriving from the user and leaving the First Private network, to the Third Private IP address, alter the source IP address of the packets, leaving the Second Private Network to a destination on the Internet, to a Third Public IP address, receive the packets returning from the Target, at the VC's Third Public IP address and converting the destination address of the packets to the Third Private IP address, resolve the tunnel from the Peer Hashtable using the Third Private IP address, alter the destination address back to the second Private Address, and send the packet back to the user via the VPN tunnel.

15. The system according to claim 14 wherein: the user packets destined to the external Target have the Third Private IP address, unique across the VPN tunnels at the singular VC, assigned to the packets as the source address; the user packets are submittable to a second NAT; the user packets are passed to a Internet-facing interface of the VC for further travelling to the target; and the user packets' source address leaving the VC are rewritten to the external public address of a designated VC interface.

16. The system according to claim 14 wherein the respective private IP addresses of the user and the VC are pre-configured and explicitly specified in local configuration files.

17. The system according to claim 14 wherein multiple VPN users have the same second Private address configured as each user's private address for establishing VPN connectivity.

18. The system according to claim 14, wherein at least the Identifier and the Third Private IP address associated with a single user's VPN session packets are stored in the Peer Hashtable and are retrieved for identifying the VPN tunnel corresponding to the user, wherein the packets returning from the Target are routed into the VPN tunnel identified.

19. The system according to claim 14 wherein the user's authentication is first submitted to a front-end AP system and at the front-end AP is subsequently submitted for further processing by a back-end AP component.

20. The system according to claim 14 wherein a standard Advanced Encryption Standard (AES) is used.

21. The system according to claim 14 wherein, the user with the AP is authenticated via the VC through a VPN application deployed locally at a user computing device.

22. The system according to claim 14 wherein, upon successful proof of a legitimate VPN user identity to the AP, a first access authorization for the user to access VPN service is received via the VC and the user's Public Key is provided to the VC.

23. The system according to claim 14, wherein the AP receives the user's access credential and evaluates if the user is a legitimate VPN service user by comparing the credentials provided with a user database record.

24. The system according to claim 23, wherein the VPN tunnel is established upon determining that the request is from a legitimate VPN service user.

25. The system according to claim 14, wherein the descriptors of the session that the packets of a particular user belong to, within the Peer Hashtable, includes at least the Second Private IP address, the Third Private IP address, a Public Key of the corresponding user, and an Index value, produced during a handshake phase of the VPN tunnel establishment.

26. The system according to claim 14, wherein the descriptors of the session that the packets of a particular user belong to, are split into at least two Peer Hashtables, of which one comprises descriptors for an initial handshake, including at least the user's Public Key PubKey_1, and the other comprises descriptors for the established VPN connection, including at least an Index value within the packets.

27. The method according to claim 1, wherein the identifier is a public key of the user.

28. The system according to claim 14, wherein the identifier is a public key of the user.

Description

DESCRIPTION OF DIAGRAMS

[0056] FIG. 1 is a block diagram of an exemplary architectural depiction of components and protocols.

[0057] FIG. 2 is a block diagram of an exemplary network layout.

[0058] FIG. 3 is a block diagram of an exemplary Authentication Platform setup and protocols.

[0059] FIG. 4 is an exemplary process/flow diagram.

[0060] FIG. 5 illustrates a computing system 300 in which a computer readable medium 306 may provide instructions for performing any of the methods disclosed herein.

DETAILED DESCRIPTION

[0061] Some general terminology descriptions may be helpful and are included herein for convenience and are intended to be interpreted in the broadest possible interpretation. Elements that are not imperatively defined in the description should have the meaning as would be understood by the person skilled in the art.

[0062] VPN user—a person or a business entity that is using VPN services. As a standard placed within a client-grade network, working over such transport links as Wi-Fi, mobile data networks, residential networks. VPN user initiates and establishes the encrypted VPN connection to a VPN Concentrator.

[0063] User device—a computing device where a person installs and executes the application that delivers VPN connectivity.

[0064] VPN Concentrator—a computing device attached to a computer network that accepts VPN users' requests for establishing encrypted connection, or tunnel, and is the endpoint of such encrypted connections from multiple VPN users. As a standard with VPN tunneling protocol endpoints, on establishing a VPN connection, or tunnel, with a VPN user VPN concentrator becomes the default gateway for the VPN user.

[0065] Target or Target server—a server serving any kind of content accessible over multiple protocols over the Internet. Most often a device placed within a datacenter network of high reliability and capability.

[0066] Network—a digital telecommunications network that allows nodes to share resources. Examples of a network: local-area networks (LANs), wide-area networks (WANs), campus-area networks (CANs), metropolitan-area networks (MANs), home-area networks (HANs), Intranet. Extranet, Internetwork, Internet.

[0067] Tunneling or Tunnel—a protocol that allows for the secure movement of data from one network to another. Tunneling involves allowing private network communications to be sent across a public network, such as the Internet, through a process called encapsulation. The encapsulation process allows for data packets to appear as though they are of a public nature to a public network when they are actually private data packets, allowing them to pass through unnoticed. Encapsulation allows the packets to arrive at their proper destination. At the final destination, decapsulation and decryption occur.

[0068] Authentication platform—the component of the VPN service core infrastructure serving the authentication, authorization and accounting requests from the VPN service front-end components facing the user.

[0069] Peer Hashtable—a dynamically maintained storage for registering all VPN user sessions undergoing Network Address modification while traversing the VC. In some embodiments the format of the hash table may define the unique Peer, or the unique Tunnel/PN, as follows:

[0070] PubKey_1: PrivIP_2: LocalIP=PrivIP_3

[0071] In some embodiments the unique identifier for a user may be a pair of credentials, or just a username, with the unique Peer defined as follows:

[0072] Username: PrivIP_2: LocalIP=PrivIP_3

[0073] The primary purpose of Peer Hashtable is to register the initial and resultant private IP addresses of the VC endpoint for a particular VPN user's session, e.g. Second Private IP address and Third Private IP address, as well as the user's unique identifier that can be a Public Key, or a username, which serves as the key field of the record. The records are dynamically added and removed to the table due to the VPN sessions being opened and closed at the VC. In some embodiments the lifecycle of the Peer Hashtable may be aligned to the status of the VC—the table created when the VC is started and is scrapped when the VC is switched off or the VPN service related processes are stopped.

[0074] FIG. 1 illustrates the basic components of the example embodiment of the system comprising user 100, VPN concentrator 110, Target server 120 and Authentication Platform 130. The communication instances between the components may include VPN connectivity between user 100 and VC 110, Authentication, Authorization and Accounting (AAA) data exchange between VC 110 and AP 130, and requesting and obtaining the content by User 100 from a Target 120.

[0075] FIG. 2 displays the basic network setup and main network endpoints, as well as their connectivity details, comprising an exemplary embodiment of the system. While connecting to VC 110 via a VPN tunnel, user 100 and VC 110 employ the public IP addresses (PubIP_1 for the user, PubIP_2 for the VC) that both possess and that is pre-configured, for connecting their physical interfaces, as well as two private IP addresses (PrivIP_1 for the user 100 and PrivIP_2 for the VC 110) for connecting the virtual VPN tunnel interfaces. In some embodiments, the private IP addresses used during this stage are pre-configured and explicitly specified in the local configuration files of both endpoints—user 100 and VC 110. Both private addresses PrivIP_1 and PrivIP_2 belong to the same private network 108. Moreover, multiple VPN users have the same PrivIP_1 configured as their private address for establishing VPN connectivity. Technical measures described below allow for such multiple identical user endpoint IP configuration to coexist.

[0076] After the VPN tunnel is established and the packets are sent therethrough to a destination on the networks behind the VC 110. Then, the packets are operated upon by the VC 110 so that a new private IP address is assigned to the packets as their source address—PrivIP_3. Thus, the first NAT happens. The private IP PrivIP_3 belongs to the private network 118.

[0077] The corresponding record of this session, including the source address substitution, is entered and kept within the Hashtable 112 in a format specified below. The purpose of this record is to keep the original private IP-based connection of the VPN tunnel and the NATed connection over the network 112 as related, allowing for packets to be switched seamlessly between them.

[0078] If User 100 reaches for the target on the Internet network, the packets within the Network 118 must further be operated upon in order to traverse public networks. Traversing the gateway of the Network 118, the outbound packets are once again subjected to NAT, this time going through the public interface of VC 110, with the public IP PubIP_3 assigned as the source address of the packets. Thus, if User 100 reaches for the target on the Internet, the packets within the Network 118 must further be operated upon in order to traverse public networks. Traversing the gateway of the network 118, the outbound packets are once again subjected to NAT, this time going through the public interface of VC 110, with the public IP PubIP_3 assigned as the source address of the packets. Thus, the second NAT happens, allowing the packets to reach a destination on the Internet.

[0079] Since the source addresses of the packets within the network 118 are unique, the second NAT is an industry standard type of network address translation, with the sessions traced through a regular NAT table that is part of a standardized network stack functionalities for modern operating systems. The packets returning from the Internet are converted back to network 118 addresses in accordance with the records within the NAT table.

[0080] However, the user endpoints in network 108 do not possess unique IP addresses. Therefore, it is necessary to trace the packets arriving from network 118 to a session happening across network 108. The records in the Peer Hashtable 112 provide for that, allowing the packets to have their source IP address to be again converted to the original PrivIP_2 from the network 108 and attached to a particular user's 100 VPN session, i.e. directed to the corresponding VPN tunnel 106 and ultimately reach user's 100 computing device.

[0081] FIG. 3 portrays an example of the AAA data exchange between the VC 110 and AP 130, where User 100 initiates the connection to VC 110, providing the user's Public Key PubKey_1 for establishing the VPN tunnel foremost, and also to find the user in the VPN service customer records at AP 130.

[0082] FIG. 4 demonstrates the operation of an example system implementing the protocols for client privacy-oriented VPN access at a VPN Concentrator (VC) 110, mediated by an Authentication Platform (AP) 130. The entities in the system include at least a user 100 and/or a VPN application 102 (e.g., software component implementing the VPN access system and protocols) operated by the user 100, an AP 130, and an VC 110. In some implementations, there is an existing account relationship between the AP 110 and the VC 110, such that the VC 110 will allow a user 100 to access its services if the user 100 provides proof that it is registered with the AP 130. The user may also have account relationships with the other parties.

[0083] In an initial stage, a user first registers with the AP to establish an account with the AP. The account can be based on a pair of user credentials (e.g., a strong credential that is a data string used in a cryptographic function, or a username-password pair) for use at the AP. By using the method described in this specification, after performing the initial authentication with the VPN service provider through whatever means the provider made available, the user can establish a VPN tunnel through a VC using a single cryptographic key, e.g. a Public Key, and the corresponding cryptographic functions. In an implementation of the invention the VC may not contain any information about the user throughout the entire time the user is connected to VC through a VPN tunnel, except the Public Key generated for the user during the initial registration.

[0084] An AP verifies user access authorization on behalf of VCs and may provide a selective disclosure of user properties to the VC, e.g. username of the connecting client. The AP can itself be a service or content provider that holds certain user information. The AP can obtain the user information through user registration (sometimes with verification documents from other authorities). An example AP can be an authentication service provider based on RADIUS protocol, that already possesses some information of a user through the registration process. The systems and protocols disclosed herein apply to processes that allow an AP to manage users and to further allow users to access a VC under privacy constraints.

[0085] In some implementations, the AP may be based on a multi-tier architectural principle, whereas the user's authentication is first submitted to a front-end AP system and at the front-end AP is subsequently submitted for further processing by a back-end AP component.

[0086] User authentication at the AP can be accomplished through a client identification system utilizing public-key cryptography, where VC forwards to AP the Public Key the user provided for establishing the VPN tunnel, and AP evaluates the Public Key comparing it to the user records kept within the AP, and replies with “Access granted” or “Access denied” depending on the successful identification of the corresponding user within the AP records. The AP can also exchange verifiable signatures with a user or VC using techniques of public-key cryptography. In some implementations, the AP can provide privately verifiable signatures that can only be verified by the AP itself. As an example, in some embodiments the encryption can be a standard AES method, among others, in some mode of encryption.

[0087] Once the AP receives and is satisfied with the user's proof of identity previously registered with the AP and submitted through VC, the AP can provide a confirmation of the user's access authorization and/or selective disclosure of certain user properties to the VC. In some implementations, the AP can sign the reply with an AP signature.

[0088] Any of the above embodiments herein may be rearranged and/or combined with other embodiments. Accordingly, the concepts herein are not to be limited to any particular embodiment disclosure herein. Additionally, the embodiments can take the form of hardware entirely or comprising both hardware and software elements. Portions the embodiments may be implemented in software, which includes, but is not limited to, firmware, resident software, microcode, etc. FIG. 5 illustrates a computing system 300 and which a computer readable medium 306 may provide instructions for performing any of the methods disclosed herein.

[0089] Furthermore, the embodiments can take the form of a computer program product accessible from the computer readable medium 306 providing program code for use by or in connection with a computer or any instruction execution system. For the purposes of this description, the computer readable medium 306 can be any apparatus that can tangibly store the program for use by or in connection with the instruction execution system, apparatus, or device, including the computer system 300.

[0090] The medium 306 can be any tangible electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device). Examples of a computer readable medium 306 include a semiconductor or solid-state memory, magnetic tape, a removable computer diskette, a random-access memory (RAM), NAND flash memory, a read-only member (ROM), a rigid magnetic disk, and an optical disk. Some examples of optical disks including compact disk—read only memory (CD-ROM), compact disk—read/write (CD-R/W), and digital versatile disc (DVD).

[0091] The computing system 300, suitable for storing and/or executing program code, can include one or more processors 302 coupled directly or indirectly to memory 308 through a system bus 310. The memory 308 can include local memory employed during actual execution of the program code, bulk storage, and cache memories which provide temporary storage of at least some program code in order to reduce the number of times code is retrieved from bulk storage during execution. Input/output or I/O devices 304 (including but not limited to keyboards, displays, pointing devices, etc.) can be coupled to the system either directly or through intervening I/O controllers. Network adaptors may also be coupled to the system to enable the computing system 300 to become coupled to other data processing systems, such as through host systems interfaces 312, or remote printers or storage devices through intervening private or public networks. Modems, cable modem, and Ethernet cards are just a few of the currently available types of network adapters.

[0092] The present system(s) and method(s) can be understood more readily by reference to the instant detailed description, examples, and claims. It is to be understood that the system(s) and method(s) detailed herein are not limited to the specific systems, devices, and/or methods disclosed unless otherwise specified, as such can, of course, vary. It is also to be understood that the terminology used herein is for the purpose of describing particular aspects only and is not intended to be limiting.

[0093] The instant description of the system(s) and method(s) detailed herein is provided as an enabling teaching of the system(s) and method(s) detailed herein in their best, currently known aspect. Those skilled in the relevant art will recognize that many changes can be made to the aspects described, while still obtaining the beneficial results of the present system(s) and method(s) detailed herein. It will also be apparent that some of the desired benefits of the system(s) and method(s) detailed herein can be obtained by selecting some of the features of the system(s) and method(s) detailed herein without utilizing other features. Accordingly, those who work in the art will recognize that many modifications and adaptations to the system(s) and method(s) detailed herein are possible and can even be desirable in certain circumstances and are a part of the system(s) and method(s) detailed herein. Thus, the instant description is provided as illustrative of the principles of the system(s) and method(s) detailed herein and not in limitation thereof.

[0094] As used herein, the singular forms “a,” “an” and “the” include plural referents unless the context clearly dictates otherwise. Thus, for example, reference to a “body” includes aspects having two or more bodies unless the context clearly indicates otherwise.

[0095] Ranges can be expressed herein as from “about” one particular value, and/or to “about” another particular value. When such a range is expressed, another aspect includes from the one particular value and/or to the other particular value. Similarly, when values are expressed as approximations, by use of the antecedent “about,” it will be understood that the particular value forms another aspect. It will be further understood that the endpoints of each of the ranges are significant both in relation to the other endpoint, and independently of the other endpoint.

[0096] As used herein, the terms “optional” or “optionally” mean that the subsequently described event or circumstance may or may not occur, and that the description includes instances where said event or circumstance occurs and instances where it does not.

[0097] Although several aspects of the system(s) and method(s) detailed herein have been disclosed in the foregoing specification, it is understood by those skilled in the art that many modifications and other aspects of the system(s) and method(s) detailed herein will come to mind to which the invention pertains, having the benefit of the teaching presented in the foregoing description and associated drawings. It is thus understood that the system(s) and method(s) detailed herein is not limited to the specific aspects disclosed hereinabove, and that many modifications and other aspects are intended to be included within the scope of the appended claims. Moreover, although specific terms are employed herein, as well as in the claims that follow, they are used only in a generic and descriptive sense, and not for the purposes of limiting the described system(s) and method(s) detailed herein.