WO2013151500A1

WO2013151500A1 - Method and system for forming a virtual private network

Info

Publication number: WO2013151500A1
Application number: PCT/SG2012/000118
Authority: WO
Inventors: Anantharaman Lakshminarayanan; Arunashis GHOSE; Preeti PRABHU KAVOUR
Original assignee: Itwin Pte Ltd
Priority date: 2012-04-04
Filing date: 2012-04-04
Publication date: 2013-10-10

Abstract

A method and system for forming a virtual private network (VPN) between a host system and a remote system via a data link. The method comprises providing a first module and a second module initially connected to each other; connecting the first module to the host system; associating the first module, the second module and the host system with each other; disconnecting the second module from the first module; and upon connecting the removed second module to the remote system, forming the VPN between the host system and the remote system for accessing the host system via the data link.

Description

METHOD AND SYSTEM FOR FORMING A VIRTUAL PRIVATE NETWORK

TECHNICAL FIELD

The present invention relates broadly to a method and system for forming a virtual private network (VPN) between a host computer and a remote computer.

BACKGROUND

VPNs have been widely used to provide secure access to a central organizational network. For example, a user may require a VPN between his home computers and office computer network so that he can access his office computers (PCs), printers and others networked resources from his home as if his home computer is part of this office network. Traditionally, large corporations make sizeable investments to establish Remote Access VPN for the entire organization. The VPN clients typically reside on mobile computers from which users can dial-in to the office when required. However, for personal use and small companies, such cost and complexity may not be justified. Setting up a VPN can be a complicated process often requiring complex hardware and dedicated technical expertise.

There are three major families of VPN implementations: (1 ) Internet Protocol Security (IPSec) VPN which is implemented in the kernel space and sometimes paired with Layer 2 Tunneling Protocol (L2TP), (2) Point-to-Point Tunnelling Protocol (PPTP) VPN which relies mostly on Point-to-Point Protocol (PPP) for the implementation of security functionalities, and (3) Secure Sockets Layer (SSL) VPN, which uses well standardized SSL/Transport Layer Security (TLS) for security functionalities. SSL VPNs are the most common form of Remote Access VPNs implemented today because they are cross- platform, network address translation (NAT)-friendly with multiple platform support. There are many different proprietary and open-source VPN software and hardware solutions that users can use to connect two computers themselves, but none of them are simple enough to setup and configure for people who are not technically inclined.

Currently, one option for the small and medium enterprises (SMEs) is to use the system and method disclosed in US Patent Publication No. 2011/0040971 A1 , the contents of which are hereby completely incorporated by reference, to access their files remotely. However, this does not give them access to the network resources and remote subnet.

A need therefore exists to provide a VPN that seeks to address or reduce one or more of the above problems. SUMMARY-

In accordance with a first aspect of the present invention, there is provided a method for forming a virtual private network (VPN) between a host system and a remote system via a data link, the method comprising: providing a first module and a second module initially connected to each other; connecting the first module to the host system; associating the first module, the second module with each other; disconnecting the second module from the first module; and upon connecting the removed second module to the remote system, forming the VPN between the host system and the remote system for accessing the host system via the data link.

The step of forming the VPN between the host system and the remote system may comprise: obtaining a network address of the host system; mutually authenticating the first module and the second module; and securely connecting the remote system to the host system via the data link. The host system may be disposed in a first subnet, and accessing the host system may comprise accessing resources on said first subnet. The method may further comprise sending information from the host system to the remote system via the data link; and separating information destined for the remote system using a virtual network interface.

The step of automatically forming the VPN between the host system and the remote system may further comprise configuring the remote system to be accessible by the host system, thereby forming a bidirectional VPN. The remote system may be disposed in a second subnet, and accessing the remote system may comprise accessing resources on said second subnet.

The method may further comprise installing a network address translator (NAT)-type system in each of the host system and remote system for routing traffic between the first subnet and the second subnet. The host system and the remote system can be accessed simultaneously if the first and second subnets have non-overlapping address ranges.

The resources may comprise one or more of a group consisting of Windows file sharing, client- server applications, network printers, Internet access and web-based applications.

The method may further comprise routing the data link through a trusted third party server. The method may further comprise providing a firewall between the third party server and at least a respective one of the host and remote systems.

The first and second modules may comprise USB modules and connecting the first and second modules to the host and remote systems may comprise connecting to respective USB ports.

The first and second modules may be interchangeable. _

3

The host system may-comprise one system of a plurality of systems, and . the.first-module may__ be movable to any other system of the plurality of systems, for forming a VPN between said other system and the remote system.

The method may further comprise encrypting all data between the host system and the remote system using a hardware key.

In accordance with a second aspect of the present invention, there is provided an access system for forming a virtual private network (VPN) between a host system and a remote system via a data link, the access system comprising: a first module and a second module, the first and second modules being associated with each other; wherein the first module is capable of being connected to the host system and the second module; and the second module is capable of being disconnected from the first module, and connected to the remote system such that the VPN is formed between the host system and the remote system for accessing the host system via the data link.

The first module and the second module may be associated with each other and with the host system.

The access system may be further configured to obtain network address of the host system; mutually authenticate the first module and the second module; and securely connect the remote system to the host system via the data link, for forming the VPN between the host system and the remote system.

The host system may be disposed in a first subnet, and resources on said first subnet may be accessible via the host system. The access system may further comprise means for sending information from the host system to the remote system via the data link, and information destined for the remote system may be separated using a virtual network interface.

The remote system may be configured to be accessible by the host system such that a bidirectional VPN may be formed between the host system arid the remote system.The remote system may be disposed in a second subnet, and resources on said second subnet may be accessible via the remote system.

The access system may further comprise a network address translator (NAT)-type system installed in each of the host system and remote system for routing traffic between the first subnet and the second subnet.The host system and the remote system can be accessed simultaneously if the first and second subnets have non-overlapping address spaces.

The data link may be routed through a trusted third party server.The access system may further comprise a firewall between the trusted third party server and at least a respective one of the host and remote systems.

The third party server may be disposed in a cloud network. The -first and second modules-may comprise -USB modules and the host and remote systems - may comprise respective USB ports for receiving the first and second modules.

The first and second modules may be interchangeable.

The host system may comprise one system of a plurality of systems, and the first module may be movable to any other system of the plurality of systems, for forming a VPN between said other system and the remote system.

The access system may further comprise a hardware key for encrypting all data between the host system and the remote system.

In accordance with a third aspect of the present invention, there is provided a VPN formed using the method as defined in the first aspect.

In accordance with a fourth aspect of the present invention, there is provided a computer readable medium having stored thereon computer code means to instruct a computer to execute a method of forming a virtual private network (VPN) between a host system and a remote system via a data link, the method comprising: providing a first module and a second module initially connected to each other connecting the first module to the host system; associating the first module, the second module with each other; disconnecting the second module from the first module; and upon connecting the removed second module to the remote system, forming the VPN between the host system and the remote system for accessing the host system via the data link.

BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 illustrates one embodiment of a system for providing a virtual private network between a host computer and a remote computer according to the present invention;

Figure 2A illustrates an alternate embodiment of a system for providing a virtual private network between a host computer and a remote computer according to the present invention;

Figure 2B illustrates the device of Figure 2A showing the two hardware modules in a disconnected state;

Figure 3A illustrates the connection of the system of Figures 1 and 2 to a host system;

Figure 3B illustrates the separate connections of two hardware modules associated with the system of Figures 1 and 2;

Figure 4A illustrates the separate connections of the system of Figures 1 and 2 involving a firewall and a trusted third-party server;

Figure 4B illustrates the separate connections of the system of Figures 1 and 2 involving two independent subnets with a firewall on both sides and a trusted third-party server;

Figure 4C illustrates the separate connections of the system of Figures 1 and 2 with an additional remote computer; Figure 5 illustrates a flowchart- showing- one method-for connecting and operating the system- of Figures 1 and 2;

Figure 6 illustrates a flowchart showing one method of connecting a portion of the system of Figures 1 and 2 to a remote computer system; and

Figure 7 illustrates one example of a computer system that can be used to implement the system of Figures 1-6.

Figure 8 shows a schematic diagram illustrating the overall architecture of a remote access system according to one example implementation.

Figure 9 shows a schematic diagram illustrating operations within the home computer of Figure 8 according to an example implementation.

Figure 10 shows a flow chart illustrating a method for forming a virtual private network (VPN) between a host system and a remote system via a data link according to an example embodiment.

DETAILED DESCRIPTION

Most Remote Access VPNs work one-way, which is to grant access to a client in an external network to resources inside a private network. However, users may benefit from a two-way VPN which can pull data in either direction based on need and thus provide a true interconnection between two independent subnets. This is different from complex site-to-site VPNs deployed in companies today for interconnecting huge subnets. Embodiments of the present invention provide a plug and play user-level bi-directional Remote Access VPN setup for creating virtual subnets.

Embodiments of the present invention also provide a portable solution when a point-to-point VPN is required between any two computers. The user may obtain a device embodying the invention and set-up the VPN almost instantaneously. This takes away the complexity of setting up a secure VPN from users who may lack the skill and resources required to do so.

In other words, embodiments of the present invention provide a system and method for allowing a user to create a virtual private network between a first system (herein interchangeably referred to as the host system) and a remote system. It is understood that the systems can be any computing device capable of making a remote connection. For example, the first system may be a home or office computer system, a PDA, etc. The remote connection can be, by way of example and not limitation, an internet connection, a LAN or WAN connection, an IR, Bluetooth, short-range radio channels such as Bluetooth, UWB, Wi-Fi, long-range radio channels such as GSM, GPRS, 3G, proprietary radio connections, or even wired connections such as optical links. For ease of discussion, the first system will be referred to as the host system/computer, while the remote system may also be referred to as the remote computer. - Figure 1 illustrates one embodiment of a -system -100 according to the present invention. The- . system 100 includes a first hardware module 110 and a second hardware module 120. The modules 110, 120 are interconnected to each other via a connection 130. The module 110 is configured to be connected to a host system 140, while the module 120 is configured to be connected to a remote system 150.

The connection 130 between the modules 110, 120 and the respective systems can be made, by way of example and not limitation, using a physical electrical interface. The connection 130 may be established such that a user connecting the module 110 and the module 120 is absolutely sure that these two modules are connected. The physical electrical interface may include, but is not limited to a standard USB connector, a Firewire connector, a serial interface, a parallel interface, a physical cable, and a network interface. Alternately, the connection between the modules 110, 120 may be any type of electromagnetic signal-based wireless communication (i.e. infrared, radio frequency, microwave, Bluetooth, 3G, 4G, GSM etc.).

When the connection 130 is a wireless link (e.g. through electrical or any other non-wire interface), the two modules 110 and 120 can have shared attributes, e.g. an association ID number, shared crypto key, address of the home computer, etc., such that while they are physically connected to two different computers, they may enable these two computers to create a network connection between themselves. For example, the manufacturer of system 100 can ensure that the modules 110 and 120 of system 100 are unique to each other which means that the attributes they share are unique, and as long as these two modules share this unique attributes, a Host System 140 physically connected to one of these two modules can only create a network connection to a Remote System 150 only when the other module is physically attached to the Remote System. Any other module that does not have the attribute of module 110 or 120 can never enable a computer to establish a network connection with Host System 140 or Remote System 50.

In some embodiments, the modules 110, 120 receive electrical power from the respective systems 140, 150. In alternate embodiments, the modules 110, 120 may each contain an independent power source.

Figure 2A illustrates a USB system 200 that provides a specific operational implementation of the system 100. While the following discussion will outline the use of the USB system 200, it is understood as discussed above that many other types of connections besides USB can also be used. The USB system 200 includes a HomeUSB 210 and a PortableUSB 220 each having its own male USB connector 212, 222 respectively. In this embodiment, the HomeUSB 210 is the master device. However, it is understood that the same requisite software may be resident on both the HomeUSB 210 and PortableUSB 220. Whichever device is connected to the host system 330 (see below) may become the HomeUSB 210. In other words, HomeUSB and PortableUSB are only a classification based on how the modules are used, otherwise two devices are symmetric, having same hardware and software properties and containing -same-sort of data. In other embodiments, there is no master/slave relationship between the HomeUSB 210 and PortableUSB 220. They are completely symmetric in functionality, hardware and software. The HomeUSB 210 may also be portable. It can be moved from one host system to another. The system to which it is attached is called the host system. The system to which the PortableUSB is attached is called the remote system.

Figure 2B shows the HomeUSB 210 and PortableUSB 220 in a disconnected state. As shown in this Figure, the HomeUSB 210 can be connected to the PortableUSB 220 by way of a male connector 214. PortableUSB 220 includes a corresponding female connector 224. The various operations of the USB system 200, the HomeUSB 210 and the PortableUSB 220 are described below. As discussed above with reference to Figure 1 , it is understood that the connectors 214, 224, which correspond to connection 130, are provided by way of example only. It will be appreciated that other types of connectors may be used in alternate embodiments where there no distinction between male and female connectors, making the devices symmetric in look.

As will be explained in more detail below with reference to Figures 3-7, the system 200 allows a user to initiate a secure VPN connection between the host computer and the remote computer. The system 200 provides hardware encryption and authentication. In some example embodiments, no passwords are required. A user can insert the system 200 into a USB slot on a host computer (see Figures 3 and 4). When the system 200 is inserted into the host computer for the first time, some device-resident software gets installed into the host computer and keeps on running as long as the system 200 is connected to the host computer. With the help of this installed software module, a cryptographic key is generated that is shared between the HomeUSB and the PortableUSB. In some implementations, the shared cryptographic key can be generated by just HomeUSB and PortableUSB without help from the installed software.

The PortableUSB 220 may then be removed, leaving the HomeUSB 210 plugged into the host computer, and connected to a network. The user inserts the PortableUSB 220 into a USB slot on a remote system. Software is downloaded onto the remote system from the PortableUSB 220, gets installed, and, with the help of this software, a secure VPN connection is established between the remote computer and the home computer, allowing the user to securely access the system and the subnet connected to the HomeUSB 210. A detailed discussion of the process is provided below with reference to Figures 5 and 6.

After the generation of the cryptographic keys, the HomeUSB 210 and the PortableUSB 220 may both be removed from the home computer and separated from each other and inserted into two different systems. In this case, the system to which the HomeUSB 210 is attached may be referred to as the home computer or home system, and the system to which the PortableUSB 220 is attached may be referred to as the remote computer or remote system. The HomeUSB 210 and PortableUSB 220 may contain integrated circuit (IC) .chips,-which are. , tamper-resistant. These IC chips may have pre-stored operating systems (OS) and software. Specific details concerning the operation of the system 200, the HomeUSB 210 and the PortableUSB 220 are discussed below. The OS as discussed above can be any known OS. Examples of such OS can include, but are not limited to Disk Operating System (DOS)-based, Microsoft Windows™ -based, Linux™-based, Novell Netware™-based, Apple MAC™-based, proprietary OS's, and the like.

The HomeUSB 210 and PortableUSB 220 may contain IC chips to enable internet access to systems connected thereto via e.g. IP/3G/Wifi or other technologies. Computers to which they are connected, e.g. 330 and 340 (Figure 4A), can connect to the internet after they are inserted into the computer.

In some embodiments, the HomeUSB 210 and PortableUSB 220 may have markings, LED lights, audio cues or other indicators (not shown) to show that the HomeUSB 210 and PortableUSB 220 are compatible. The indicators allow a user who, for example, has multiple home computers to access each of them individually using a separate system 100, 200. In alternate embodiments, a single PortableUSB 220 may be used to access multiple HomeUSBs 210. In other alternate embodiments, multiple PortableUSBs 220 may access a single HomeUSB 210. Similarly, multiple HomeUSBs 210 may access and be accessed by multiple PortableUSBs 220. In alternate embodiments, the HomeUSB 210 and PortableUSB 220 may have indicators 211 , 221 to indicate their status. For example, when using LED lights for indicators 211 , 221 , red lights may indicate data is being transferred, while a change in light colors from red to green may indicate completion of the data transfer etc.

Figure 3A illustrates one embodiment of a system 300, capable of using the system 100, 200. In this embodiment, the connector 212 of the system 200 is plugged into a corresponding port 320 of a host system 330. The specific operation of the system 200 with the host system 330 is discussed below with respect to Figure 5.

Figure 3B illustrates an expanded version of the system 300 that uses the USB system 200.

The connector 222 of the PortableUSB 220 has been inserted into a corresponding port 335 of a remote system 340. Once the PortableUSB 220 has been inserted, the remote system 340 establishes a VPN connection 350 with the host system 330 connected to the HomeUSB 210. In some embodiments, the connection 350 may be an Internet connection. However, the connection may be any type of hard wired, optical, or wireless connection known to those of ordinary skill in the art.

For some applications using the system 100, 200, it may be advantageous to use a trusted third-party to facilitate the connection between the remote system 340 and the host system 330. Figure 4A illustrates an alternate embodiment of a system 400 that is capable of using the system 100, 200. As with the system 300, the connector 212 of the HomeUSB 210 is plugged into the corresponding port 320 of the host system 330. The connector 222 of the PortableUSB 220 has been inserted into the corresponding port 335 of the remote system 340. Once the PortableUSB 220 has been inserted, the remote system 340 establishes a secure VPN-connection 350 (Figure 3B) with-the host system-330.via the HomeUSB 210. In this embodiment, the host system 330 is behind a firewall 420. A data path 410 connects the HomeUSB 210 to the firewall 420. Data can be routed to/from the firewall 420 via data path 445 to a trusted third-party server 430, and to/from the trusted third-party server 430 to the PortableUSB 220 via data path 440. In some embodiments, the trusted third-party server 430 is disposed in a cloud network. Details of the operation will be discussed below with respect to Figures 5- 7.

The third-party server 430 can be useful in several applications. In the embodiment shown in Figure 3, if the host system 330's network address is static, this address can be stored in the PortableUSB 220. When the user at the remote system 340 desires to connect to the host system 330, the remote system 340 obtains the host system's address from the PortableUSB 220 and can connect to host system 330. The network address of the host system 330 is part of the initialization attribute. This will be discussed in more detail below with reference to Figures 5 and 6.

To provide additional security, it is possible to use the trusted third-party 430 for managing the network address of the host system 330. When the system 100, 200 is initialized, the system 100, 200 is assigned a randomly generated (e.g. at least 20-byte) Pairing Identifier (PI). This PI, along with the network address of the host system 330, is registered with the trusted third-party 430 over a secure link (using, for example, secure sockets layer (SSL)) during initialization. This PI is also stored on the PortableUSB 220, instead of the actual host system network address. When the remote system 340, using the PortableUSB 220, desires to connect to the host system 330, it first contacts the trusted third- party 430 and presents the PI. The trusted third-party 430 then checks whether the PI is registered with it and whether it is still valid. If so, the trusted third-party 430 sends the host system network address back to the remote system 340. In some embodiments, these exchanges between the trusted third-party 430 and the system 100, 200 can be protected using, e.g. SSL.

Additionally, the system 400 may facilitate easier data transfer when dynamic IP addressing is used on the host system 330. Dynamic IP addressing may be used, for example, when using a network address translator or when the host system 330 is behind the firewall 420. In this scenario, each time the IP address of the host system 330 changes, the HomeUSB 210 will inform the trusted third-party server 430 of the changes. In some embodiments, the user would be expected to connect the HomeUSB 210 and the host system 330 to the trusted third-party server 430 periodically to validate and update the configuration. In other embodiments, if the host system 330 is unable to connect to the trusted third-party server 430, the HomeUSB 210 will automatically disable itself. Alternative solutions to the use of dynamic IP addresses may be, by way of example and not limitation, the use of hole punching techniques (e.g. Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) hole punching). Hole punching techniques establish direct connections between systems that are behind firewalls instead of routing all traffic through a trusted server like the server 430. Figure 4B illustrates an alternate-embodiment of a system 450 where the host system 330 and- - - the remote system 340 are both in independent subnets 448 and 447 respectively. Data paths 411 and

441 connect the host system 330 to a third-party server 430 via a firewall 420. Similarly, data paths 412 and 442 connect the remote system 340 to the third-party server 430 via a firewall 421. The third-party server 430 may be disposed in a cloud network. A Virtual Private Network 446 is established between the host system 330 and the remote system 340 via the third party server 430. After the connection is established, the two systems appear to be in an independent virtual subnet 449 with its own address range. This means that applications that run on systems in the same subnet, e.g. Windows file sharing, client server applications like remote desktop, etc. can now be run between the two systems as if they belong to the same subnet even when physically they are connected to two independent subnets. In some implementations, A NAT may be installed in the host system 330 to route the traffic correctly between the virtual subnet 449 and the real subnet 448, which may enable the remote system 340 to access resources from the home/host subnet 448 as if it were a system in the subnet 448. For example, it may be allow the remote system 340 to use the printer from the home subnet 448. Similarly, another NAT may be installed in the remote system 340 to route traffic between the virtual subnet 449 and the real subnet 447, which may enable the host/home system 330 to access resources from the remote subnet 447 as if it were a system in the subnet 447.

The Virtual Private Network 446 is bidirectional in that the host system 330 can access remote subnet 447 and the remote system 340 can access the host subnet 448 simultaneously, provided the two subnets have non-overlapping address ranges. This VPN 446 can be used to bypass internet censorship. For instance if the remote subnet 447 is barred from accessing a particular website then the request for the website can be routed through the host system 330 by configuring the routing table to use the VPN 446. If the said website is not barred in host subnet 448, the response to the request will be routed from the host system 330 back to the remote system 340, thus allowing the remote system 340 to access the barred website. The VPN may also be used to allow access to web-based corporate client server applications, internal corporate web sites and other corporate resources like printers etc. in a similar manner. To the corporate server, the remote user will appear to be inside the corporate network.

Figure 4C illustrates an alternate embodiment of a system 470 that is capable of using system

100, 200. As with the system 300, the connector 212 of the HomeUSB 210 is plugged into the corresponding port 320 of the host system 330. The connector 222 of the PortableUSB 220 has been inserted into the corresponding port 335 of the remote system 340. Further, an additional HomeUSB

210a can be paired with an additional PortableUSB 230. The HomeUSB 210a can be plugged into the remote system 340 via a connector 212a, into a corresponding port 320a of the remote system 340, while the PortableUSB 230 can be plugged via a connector 232, into a corresponding port 337 of an additional remote system 370. The PortableUSB 230 may include s corresponding female connector 224a, that facilitates connection to the HomeUSB 210a via connector 214a.

Once the PortableUSB 220 has been inserted, the remote system 340 establishes a secure VPN connection 350 (Figure 3B) with the host system 330 via the HomeUSB 210 connected to the host system 330. The PortableUSB 230, once inserted into the corresponding port 337 of the remote system 370, can establish a secure VPN connection 360 with the host system 330 via the HomeUSB 210a. It is understood that additional remote systems and PortableUSBs may be added to this configuration. Similarly, the same configuration could be used with the system 300 to extend the connections to additional remote systems.

Figure 5 illustrates one embodiment of a flowchart showing one method, designated generally as reference numeral 500, for connecting and operating the system 100, 200. While the following process discussion uses the embodiment of the system 200 described above, it is understood that similar steps apply regardless of the specific hardware and connections that are used. As previously stated, all configurations of the systems 100, 200, 300, 400 and 450 are to be understood to fall within the scope of the present invention .

The method 500 begins with a user inserting the connector 212 of the HomeUSB 210 into the corresponding port 320 of the host system 330 (designated as HomeC in Figure 5), as shown with reference numeral 502. In an example embodiment, the host system 330, running on an operating system installed by the user, may have a pre-installed USB software module that effects initialization between the host system 330 and the HomeUSB 210. For example, Windows™ based operating systems will detect the insertion of the HomeUSB 210. In some applications, the operating system on the host system 330 may also automatically execute programs stored on the HomeUSB 210. Programmers skilled in USB programming will be familiar with this type of programming.

The HomeUSB 210 then powers-up and initializes one or more internal software modules, as shown with reference numeral 504. These software modules allow the HomeUSB 210 to determine if the PortableUSB 220 is attached, as shown with reference numeral 506. At this time, one or more of the software modules stored on the HomeUSB 210 may also be loaded onto the host system 330 to allow various communications from the HomeUSB 210 and PortableUSB 220 to be displayed to the user. The PortableUSB 220 may also have one or more internal software modules that communicate with the HomeUSB 210 and/or the host system 330. Using the initialized software modules on the HomeUSB210 and PortableUSB 220, if the PortableUSB 220 is attached, as shown with reference numeral 508, the HomeUSB 210 checks to see if the PortableUSB 220 is compatible, as shown with reference numeral 512. As discussed above, it is possible to configure the system 200 such that a single HomeUSB 210 is compatible with only one PortableUSB 220, thus providing an added measure of security to prevent unauthorized access to the data that the user wishes to protect. Alternately, multiple PortableUSBs 220 may be configured for a -single HomeUSB 210,. as previously discussed. .

The situation where the PortableUSB 220 is not attached is described in more detail below.

If the PortableUSB 220 is not compatible, as shown with reference numeral 514, the user is instructed to remove the PortableUSB 220 and insert an alternate/correct PortableUSB 220, as shown with reference numeral 516. Step 506 is then repeated. If the PortableUSB 220 is compatible, as shown with reference numeral 518, the system 200 then deletes all prior association information contained on both the HomeUSB 210 and PortableUSB 220, generates a shared key, and initializes both the HomeUSB 210 and PortableUSB 220, as shown with reference numeral 520. When a HomeUSB 210 and PortableUSB 220 are paired together and powered, they become

"initialized". In the "initialized" state, the HomeUSB 210 and PortableUSB 220, using the various software modules discussed above, are physically bound to the host system330 (and user login-ID) that it is associated with. The physical binding/association is enforced using unique computer identifiers, e.g. the MAC address, Hard-disk ID, etc. on desktop computers. After initialization, the HomeUSB 210, the PortableUSB 220 and host system 330 all share a randomly selected long system pairing identifier, PI, that is generated using the software modules loaded onto the HomeUSB 210. In a preferred embodiment, the PI is at least 20-Bytes long. In some embodiments, an initialized HomeUSB 210 can be un-initialized and then freshly re-initialized by pairing with a new PortableUSB 220. The HomeUSB 210 and PortableUSB 220 can also be un-initialized using software, e.g. a user could right click on a USB file system icon on the desktop and select the de-initialize option.

After initialization of the system 200, and using one or more of the software modules discussed above, the HomeUSB 210 and PortableUSB 220 share a MASTER Key, the network address of the host system 330, and the randomly selected system 200 Pairing Identification number. In some embodiments, after initialization, the HomeUSB 210 and host system 330 share the randomly selected system 200 Pairing Identification number and the host system's 330 unique computer identifier. The computer identifiers may be derived from one or more of the host system's 330 hardware and software identifiers. These can include, but are not limited to, the hard-disk ID (a unique number for every hard disk), the MAC address (a unique number associated with every network interface card), and/or a user Login-ID. A specific discussion of the procedures involved in these steps, and of the use of encryption keys in general, is provided below.

Once the HomeUSB 210 and PortableUSB 220 are initialized, a software module residing on the HomeUSB 210 associates (binds) the HomeUSB 210 and PortableUSB 220 to the host system 330, as shown with reference numeral 522. The user then should remove the PortableUSB 220 from the physical attachment with the HomeUSB 210, as shown with reference numeral 532. Upon unplugging the PortableUSB 220, the system checks whether the user has removed the HomeUSB 210, as shown with reference numeral 533. Then, software module that facilitates the connection between the HomeUSB 2-10 and PortableUSB -220 terminates. This ends the initial . setup, as ..shown— with reference numeral 544.

In some embodiments, if the operating system of the host system 330 does not detect the insertion of the HomeUSB 210 into a corresponding port, or if the software modules loaded onto the host system 330 are not set to automatically initiate the programs stored on the HomeUSB 210 and/or PortableUSB 220, the user may manually start the process discussed above. As previously stated, the HomeUSB 210 and PortableUSB 220 may contain software modules that facilitate connection to a number of different operating systems. In a preferred embodiment, once the HomeUSB 210 is inserted into the host system 330, all of the steps concerned with initializing the devices, associating the HomeUSB 210, PortableUSB 220 and host system 330, generating the key information, and launching the VPN software, are performed automatically. The user simply needs to insert the HomeUSB 210 into the host system, and the VPN software will be activated to run the necessary steps for connecting the host system to the remote system.

Returning to step 506, if the PortableUSB 220 is not attached to the HomeUSB 210, as shown with reference numeral 510, the software modules running on the HomeUSB 210 perform a check to determine if the HomeUSB 210 has been initialized, as represented by reference numeral 534. If the HomeUSB 210 has not been initialized, as represented by reference numeral 536 (see step 520), the system informs the user that the HomeUSB 210 has not been initialized, and requests the user to connect the PortableUSB 220, as shown with reference numeral 537.

At this point, the system then checks to determine if the user has removed the HomeUSB 210, as represented by reference numeral 538. If the user removes the HomeUSB 210, as represented with reference numeral 542, the process ends, as represented with reference numeral 544. If the user does not remove the HomeUSB 210, as represented by reference numeral 540, step 506 is then repeated. The user thus has the option of attaching the PortableUSB 220, and restarting the process from step 506, or removing the HomeUSB 210, attaching the PortableUSB 220 external to the host system 330, and restarting the process from step 502.

Returning to step 534, if the HomeUSB 210 has been initialized, as represented by reference numeral 546, the system 200 checks to determine if the HomeUSB 210 and the host system 330 have been previously associated (see step 522). This process ensures that a HomeUSB 210 that has been previously associated with another computer is not inserted into an incorrect host system 330 in error. This allows a user to remove the associated HomeUSB 210, for example, to restrict all access to the data on the host system 330, and still re-connect the HomeUSB 210 at a later time to reinstate the access without needing to re-generate keys, etc. In alternate embodiments, it is possible to associate a single HomeUSB 210 with multiple host systems 330.

If the HomeUSB 210 and host system 330 are not associated, as represented by reference numeral 550, the system informs the user that the two are not associated, as represented by reference numeral -552, and the process ends,-as represented by reference numeral 544. In a preferred - embodiment, the association process will only take place when both the HomeUSB 210 and PortableUSB 220 are connected as a unitary system 200 to the host system 330.

If the HomeUSB 210 and host system 330 were previously associated, as represented by reference numeral 554, the host system 330 starts the VPN software to facilitate the secure VPN connection between the host system 330 and the remote system 340 later, as represented by reference numeral 556. The system will periodically check to ensure that the HomeUSB 210 is still connected to the host system 330, as represented by reference numeral 558. If the HomeUSB 210 is no longer connected, as represented by reference numeral 562, the process ends, as represented by reference numeral 544. As long as the connection is maintained, as represented by reference numeral 560, the access to the home system 330 and the home subnet 448 will be available to the user via the PortableUSB 220 connected to the remote system 340. This connection will be discussed in more detail below with reference to Figure 6.

With reference to step 520, a brief discussion of the process of cryptographic key management for the embodiments of the present invention will now be discussed. When the HomeUSB 210 and PortableUSB 220 are paired together (and powered by inserting the system 200 into the host system 330), internal software modules, running in the background, create a randomly generated fresh MASTER shared key. This MASTER shared key is stored inside the USB tokens in hardware, i.e. on the chips previously discussed. The MASTER key needs never leave the USB token. All encryption/decryption operations that are done are thus hardware based. No user identification or passwords need be used. Additionally, in a preferred embodiment, the process takes place seamlessly; no user intervention of any kind is required.

The PortableUSB 220 can be removed from an initialized system 200 and inserted into a remote system 340 to enable the user to create a secure VPN connection with the host system 330. After the HomeUSB 210 and PortableUSB 220 authenticate themselves using the MASTER shared secret key resident on the HomeUSB 210 and PortableUSB 220, the two USB devices 210, 220 can set up session keys that last for the session, thus establishing a secure connection between the host system 330 and the remote system 340. This is discussed in more detail below. The host system 330 and remote system 340 thus know the session keys, but not the MASTER shared key. The authentication mechanism between the HomeUSB 210 and PortableUSB 220 can use either symmetric key or public key cryptography. Many standard authentication techniques that allow two entities to authenticate themselves using a shared key, are known to those of skill in the art. All such cryptographic systems and authentication techniques are deemed to fall within the scope of the exemplary embodiments.

When using a symmetric key based system, the shared key can be a symmetric key e.g.

Advanced Encryption Standard (AES) 256 bits, which is generated during the system 200 initialization - phase 520. When using a public key-based system, the HomeUSB 210 and PortableUSB 220 can each generate their own public-private key-pairs and exchange their public keys during the system 200 initialization phase 520.

In alternate embodiments, a one-time pad encryption may be used. The various software modules running in the background on the HomeUSB 210 and PortableUSB 220 can generate a predefined set of random numbers during the initialization phase. These random numbers are stored on each of the HomeUSB 210 and PortableUSB 220. These random numbers are unique and can serve as encryption keys for a one-time pad based encryption scheme. If large amounts of data need to be shared, then the one-time pad can be used for generating a symmetric crypto based session key that can be used for encrypting sessions. Once a key has been used as a one-time pad, it should be deleted from both the HomeUSB 210 and PortableUSB 220.

In some embodiments, the PortableUSB 220 uses a tamper-proof IC card for storing the keys. As known to a person skilled in the relevant art, a tamper-proof IC card provides additional security. However, in alternate embodiments, a tamper-proof IC card may not be required. This may create additional problems that must be accounted for. For example, an attacker may be able to obtain the shared key (stored in the PortableUSB 220) and clone the PortableUSB 220. He may then connect to the HomeUSB 210 using the PortableUSB clones until the theft of the PortableUSB 220 is noticed and action is taken. Even if the theft of the PortableUSB 220 is noticed, an attacker may still be able to record encrypted information exchanged between the PortableUSB 220 and the HomeUSB 210. Once the shared key from the PortableUSB 220 has been obtained, recorded data can be decrypted.

In some embodiments, one solution to prevent the above attacks may use a key-evolving threshold crypto-based shared key. One way to implement this solution is to use an algorithm, herein referred to as the RSA algorithm. During system 200 initialization 520 (Figure 5), the HomeUSB 210 generates an RSA key-pair. In alternate embodiments, it is possible to use a pure symmetric key-only solution even with key evolution.

Following is a discussion of the RSA solution, in which: N is the Modulus, i.e. a product of two large primes N = p * q; e is a public exponent and d is a secret exponent having a relationship:

ed = 1 mod O(N) (1 ) where "mod" is the modulus function and

<P(N) = (p-1)(q-1) (2)

Additionally, if M denotes a message, C denotes cipher text, and D denotes a cryptographic digest of message M, then, for example, to decrypt the cipher text C, the value M=C^d mod N is calculated. To sign the message M, the value D^d mod N is calculated. In the following section, PI denotes the pairing PI previously discussed, while Hash denotes cryptographic hash functions, such as SHA-1. When applying the above method, -the HomeUSB 210 can generate-a private key- d and split it into two shares such that d = di + d₂. The HomeUSB 210 can then retain one share (di) and transmit (d₂) to the PortableUSB 220. After this transmission, the HomeUSB 210 may delete d as well as d₂ from its memory. In this embodiment, di and d2 may be selected randomly from [1 ,2,...Φ(Ν) ], where: d = di + d₂mod Φ(Ν) (3)

When the PortableUSB 220 wants to authenticate itself to the HomeUSB210 (see the discussion of Figure 6 below), it generates a random number nonce. In this embodiment, the following steps are followed by both the PortableUSB 220 and the HomeUSB 210. It is understood that the steps outlined below are provided by way of example only. The below steps should be used as a guideline only.

PortableUSB 220 -» HomeUSB 210: CurrentTime, {CurrentTime}^d mod N,

{Nonce'l , TwinUSB Pairing ldentifier}^emod N,

{Woncel , TwinUSB Pairing ldentifier}^d2mod N

To implement the method, the HomeUSB 210 first checks whether the CurrentTime is within its acceptable time delay. The acceptable time frame will depend on the underlying channel used for exchanging data. Anything more than twice the normal delivery time will be considered unacceptable.

The HomeUSB 210 then computes:

{CurrentTime} ¹ mod N (4) The HomeUSB 210 then computes:

{CurrentTime}^d1 * {CurrentTime}^d2 mod N = {CurrentTime} ¹^² mod N (5) and

S= {CurrentTime}^d mod N (6) The HomeUSB 210 then computes:

Check = S^e mod N (7)

And if Check = CurrentTime, then the HomeUSB 210 has authenticated the PortableUSB 220. Next, the HomeUSB 210 determines value for:

{/Voncel , PI}^ed1mod N (8) and then computes

{Woncel , PI }^ed1 * {Noncel , PI }^ed2 mod N = Nonce , PI (9)

The HomeUSB 2 0 then verifies the Portable USB 220 Pairing Identifier. HomeUSB 210^210PortableUSB 220:

Hash(Noncel), {Nonce2, PI}^emod N,

{Nonce2, PI}^d1mod N The PortableUSB 220 first checks whether the Hash(Noncel) is correct. Since PortableUSB

220 already possess Nonce† , it just needs to compute the hash of Nonce 1 and compare it to the value sent by the HomeUSB 210.

Then the PortableUSB 220 computes:

{Nonce2, PI}^ed2mod N, then computes {Noncel, PI }^ed1 * {Nonce2, PI }^ed2 mod N = Nonce2, PI

Thus providing Nonce2 to the PortableUSB 220.

Now both the PortableUSB 220 and HomeUSB 210 have two nonces, Noncel and Nonce2 which only they share. The session key(s) can be derived from Hash (Λ/oncel , Nonce2). All communication between the HomeUSB 210 and the PortableUSB 220 is then protected using the session key.

In some embodiments, it may be desirable to ensure that disclosure of the session key (or MASTER shared key) does not disclose data that was exchanged in earlier time intervals. To accomplish this, after a certain amount of time (or number of communication runs), the HomeUSB 210 and PortableUSB 220 refresh their shares of the private key d.

At the beginning of each refresh period, let di be the private key share on the HomeUSB 210 and d₂ be the share on the PortableUSB 220. The HomeUSB 210 then computes:

di = di' + di2 mod Φ(Ν); (10) The PortableUSB 220 then computes

d₂= d₂' + d₂2 mod Φ(Ν); (11)

The HomeUSB 210 and the PortableUSB 220 then exchange di2 and d₂2. To update to their new shares, the HomeUSB then computes

Similarly, the PortableUSB 220 then computes

All the above messages are protected using the session key generated using the previous key shares. Once the HomeUSB 210 and the PortableUSB 220 have generated new shares, the old session is dropped and a new session started, starting with mutual authentication. The HomeUSB-210- and PortableUSB 220 also delete all traces of the old key shares. In a preferred embodiment, all of the key generating steps discussed above are performed internally by software modules running in the background on the HomeUSB 210, PortableUSB 220 and/or host system 330. The process runs seamlessly and no user intervention is required.

This key refresh technique prevents an attacker from decrypting prior recorded messages. For example, if we assume that an attacker has obtained the PortableUSB 220 with its current key share as d2new, that attacker may be able to retrieve d2new. Therefore, the attacker can retrieve all communication that was protected using d2new. However all communication protected using d2 (or any prior d2's) cannot be retrieved since no entity possesses d₂, as it has been deleted.

However, if an attacker is able to obtain both the HomeUSB 210 and the PortableUSB 220, and able to retrieve "d", the private key, all recorded traffic can be decrypted. Hence it is highly desirable that if theft of a PortableUSB 220 is detected, the owner of the system 200 should de-initialize the HomeUSB 210, or pair it with another PortableUSB 220 (which then deletes all prior information), so that theft of the HomeUSB 210 does not result in any data loss.

Figure 6 illustrates one embodiment of a flowchart showing one method, designated generally as reference numeral 600, for connecting the PortableUSB 220 to the remote system 340 for accessing resources through a secure VPN connection. It is understood that the PortableUSB 220 discussed here has already been initialized along with the HomeUSB 210, and appropriate encryption algorithms applied, as discussed above with respect to Figure 5.

The method 600 begins with the user inserting the PortableUSB 220 into the remote system 340 (designated as PortableC in Figure 6), as shown with reference numeral 612. Using the software resident on the PortableUSB 220, a determination is made as to whether or not the PortableUSB 220 has been initialized, as shown with reference numeral 614. If the PortableUSB 220 has not been initialized, as shown with reference numeral 616, the PortableUSB 220 informs the user that the PortableUSB 220 is not initialized, as shown with reference numeral 618, and the process ends, as shown with reference numeral 644.

If the PortableUSB 220 has been initialized, as shown with reference numeral 620, one or more software modules that are pre-loaded in the PortableUSB 220 are then loaded onto the remote system 340, as shown with reference numeral 622. These modules are designed to facilitate the connection between the PortableUSB 220 and the remote system 340, and between the PortableUSB 220 and the HomeUSB 210. The remote system 340 then obtains the address of the host system 330, as shown with reference numeral 624.

When the HomeUSB 210 and PortableUSB 220 are initialized and physically bound to the host system 330, the software that is pre-loaded onto the host system 330 will retrieve the address of the host system 330. This software module will pass the address of the host system 330 to the HomeUSB 210. The HomeUSB 210 will then -pass the address - of-the hos system 330-to the PortableUSB-220. As previously discussed, the address mentioned herein can be an IP address or an address pointer.

When an address pointer is stored on the PortableUSB 220, during the initialization phase of the HomeUSB 210 and the PortableUSB 220, the IP address (or network address) of the host system 330 is stored on the trusted third-party server 430 along with the address pointer. The address pointer is the pairing identifier. When a user wants to establish a VPN connection with the host system 330 from the remote system 340, the user then inserts the PortableUSB 220 in the remote system 340. The various software modules stored on the PortableUSB 220 are first loaded onto the remote system 340. These software modules execute code to retrieve the network address of the host system 330 or the address pointer. If the IP address of the host system 330 is available and host system 330 resides in the same physical subnet or has a public IP address, the remote system 340 can make a connection directly with the host system 330. if the host system 330 is not directly connectible or the IP address is not available, the address pointer is retrieved, and the remote system 340 uses this pointer to connect to the host system 330 where the connection is routed by the trusted third-party server 430. In some embodiments, the the trusted third-party server 430 is disposed in a cloud network.

Mutual authentication between the PortableUSB 220 and the HomeUSB 210 can then be conducted, as shown with reference numeral 626 and described above. A determination is then made as to whether or not the mutual authentication is successful, as shown with reference numeral 628. If the authentication is not successful, as shown with reference numeral 630, the user is informed that authentication has failed, as shown with reference numeral 632, and the process ends, as shown with reference numeral 644.

If the authentication is successful, as shown with reference numeral 634, the VPN software is allowed to run and connect to the host system 330 (HomeC), as shown with reference numeral 636. The user can then securely access the home subnet 448. The process then ends, as shown with reference numeral 644. As discussed above, the connection between the HomeUSB 210 and the remote system 340 via the PortableUSB 220 can be maintained as long as desired. The user of the remote system 340 may terminate the connection at any time. Termination may be effected by, for example, using the software provided on the PortableUSB 220, or by removing the PortableUSB 220 from the system 340. Similarly, a user at the host system 330 may terminate the connection.

In an example embodiment, when either the HomeUSB 210 or the PortableUSB 220 is plugged into the host system, if absent, software is installed on the system. In a Windows OS platform, the software includes two parts. The first part is system-level software, which is a device driver. The second part is a user application (hereinafter also referred to as the Manager program) that works with the driver. The device driver appears like a Network Interface Card (NIC) to the Windows IP stack and is assigned a unique IP address upon startup. For example, if it is the HomeUSB 210 that is plugged in, the IP address range of the local subnet is determined by making some system calls. The Virtual Network Interface Card of the device driver-is assigned an IP address that does not conflict with the IP — - address range used in the local subnet. The routing tables are set up for the home computer so that the computer can see the alternate path available through the new NIC.

If it is the PortableUSB 220 that is plugged in, the PortableUSB 220 requests the HomeUSB

210 for an IP address, Subnet Mask, Gateway and DNS information for the virtual subnet via the network connection between the host and remote computers. This connection can be either direct or via a trusted third party routing server, e.g. the server 430 (Figures 4A, 4B). Based on the IP address chosen for the Virtual NIC on the home computer 330, the home computer 330 may send this information to the remote computer 340. Upon receiving this information the remote computer 340 may assign the information to the Virtual NIC installed on the remote computer 340. The Virtual NIC may modify its routing tables so that the remote computer 340 can see the alternate path available through the new NIC.

Figure 8 shows a schematic diagram illustrating the overall architecture of a remote access system 800 according to one example implementation. When an IP application 802 (like Remote

Desktop, Windows File Sharing, Web Browser, etc.) in a home computer 810 wants to reach a destination address that is assigned to the Virtual NIC, the IP stack 804 forwards the packets to the

Device Driver 806. The device driver 806 then allows the User Application in the form of the Manager program 808 to pull the packets up to the application level and send the packets to the remote computer 820 directly or via the relay server 830. The packets received on the remote computer 820 are pushed, via the User Application in the form of the Manager program 818, to the Device Driver 816, and from there they are pulled up by the IP stack 814 and finally reach the IP application 812 that was targeted.

Figure 9 shows a schematic diagram illustrating operations within e.g. the home computer 810 of Figure 8 according to an example implementation. In the example shown in Figure 9, the home computer 810 has a real network interface card 902 which connects it to the internet with an IP address of 192.168.1.150, for example. When the device driver 806 is installed, a new virtual NIC 912 is visible to the home computer 810. The virtual NIC 912 may be assigned an IP address from non-conflicting IP address range, such as 10.10.1.1 with subnet mask 255.255.255.0. The routing table in the home computer 810 may be modified to use the new NIC 912 in appropriate ways as will be understood by those skilled in the art. For example, the fact that an alternate route exists through the address

10.10.1.1 and that the address 10.10.1.1 means the local computer (i.e. the computer where the software is installed, which can be the home or remote computer), for all packets destined for the address 10.10.1.X, the next hop is 10.10.1.1 and the gateway is the remote computer 820 (Figure 8).

In the example embodiment, normal TCP/IP traffic may not be affected. If an IP application

802 (Figure 8) has packets to send to the internet or to any other computer in home computer's network, the packets may be sent to the standard NIC 902's IP address of 192.168.1.150. If the IP application 802 addresses any packet- to go to -the IP -address 10.10.1. X, the IP stack 804 (Figure-8)- - may push the packet to the new Virtual Interface 912. The Device Driver 806 includes two parts. On one side, it looks like a Network interface (the virtual interface 912) so that packets can be pushed to it. On the other side, it looks like a device with which the Windows I/O Manager 916 can interact. Typically, the Device Driver 806 queues up the packets arriving from the IP stack 804 into a transmit queue 915 of user door queues 914. The User Application (i.e. the Manager program) 808 can pull the packets up to the application level using standard Windows I/O calls. Data in these packets is then encrypted by the key in the Device 910, i.e. the HomeUSB 210 (Figure 2). The packets are then sent over the Communication Framework (described above with respect to Figures 3-6) using the Real Interface 902. The Virtual Network Interface 912 is thus created to separate the packets that are destined for the remote computer 820 (Figure 8). The separation is at the IP level and hence any IP application 802 that sends data to the remote computer 820 can have all its data encrypted using the Device 910.

The software according to the example embodiments can also be configured to provide link- level encryption. It will be appreciated that, irrespective of whether the software creates an encrypted tunnel in a Network or Link layer, this encryption may remain completely transparent to any application that communicates through this tunnel.

The software available on the system 200 allows the system to operate seamlessly with respect to the user. In some embodiments, no passwords are required. No login or authentication need be performed by the user. When the HomeUSB 210 and PortableUSB 220 are combined into the system 200, a system software module may be loaded onto the host system 330. The system software module may perform system 200 initialization, and network configuration for remote subnet access as discussed above. Similarly, after the system 200 is initialized and the PortableUSB 220 is removed, a HomeUSB software module may be loaded onto the host system 330. This module may perform authentication with the PortableUSB 220, and establish the VPN connection. Additionally, when the PortableUSB 220 is inserted into the remote system 340, a PortableUSB software module may be loaded. This module may perform authentication with the HomeUSB 210, and establish the VPN connection.

There are many alternate applications of the system 200 described above. For example, once the system has been initialized, it is possible to let the PortableUSB serve as the HomeUSB for the original HomeUSB. Effectively, the HomeUSB and PortableUSB switch roles. This enables the user to initiate the VPN connection using either the PortableUSB or the HomeUSB. Additionally, it may be possible to use just one hardware module (portable), and replace the HomeUSB with a software module. The user needs to install the virtual HomeUSB module however, and manage it using software. Similarly, it is possible to use a third device such as a mobile phone to serve as the PortableUSB. As previously discussed, -it is also possible to-design a system wherein one HomeUSB supports multiple PortableUSBs. For example, a single HomeUSB can be attached to a host system, a first PortableUSB can be attached to a first remote system, a second PortableUSB can be attached to a second remote system, and the user can then access data on either of the host system or the first remote system from the second remote system. It is understood that multiple variations of the system presented are possible, and all such variations are considered to fall within the scope of the described embodiments.

Some portions of the description above are explicitly or implicitly presented in terms of algorithms and functional or symbolic representations of operations on data within a computer memory, or within the systems 100, 200. These algorithmic descriptions and functional or symbolic representations are the means used by those skilled in the data processing arts to convey most effectively the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of steps leading to a desired result. The steps are those requiring physical manipulations of physical quantities, such as electrical, magnetic or optical signals capable of being stored, transferred, combined, compared, and otherwise manipulated.

Unless specifically stated otherwise, and as apparent from the following, it will be appreciated that throughout the present specification, discussions utilizing terms such as "scanning", "calculating", "determining", "replacing", "generating", "initializing", "outputting", or the like, refer to the action and processes of a computer system, or similar electronic device, that manipulates and transforms data represented as physical quantities within the computer system into other data similarly represented as physical quantities within the computer system or other information storage, transmission or display devices.

The present specification also discloses apparatus, such as system 200, host system 330, remote system 340, and remote system 370, for performing the operations of the above-described methods (particularly Figures 5 and 6). Such apparatus may be specially constructed for the required purposes, or may comprise a general purpose computer or other device selectively activated or reconfigured by a computer program stored in the computer. The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Various general purpose machines may be used with programs in accordance with the teachings herein. Alternatively, the construction of more specialized apparatus, such as, but not limited to systems 100 and 200, to perform the required method steps, may be appropriate. The structure of a conventional general purpose computer will appear from the description below.

In addition, the present specification also implicitly discloses one or more computer programs, in that it would be apparent to the person skilled in the art that the individual steps of the methods described herein may be put into effect by computer code. The various computer programs are not intended to be limited to any particular programming language and implementation thereof. It will be appreciated that a variety of programming languages and coding thereof may-be used to implement-the teachings of the disclosure contained herein. Moreover, the computer programs are not intended to be limited to any particular control flow. There are many other variants of the computer programs, which can use different control flows, without departing from the spirit or scope of the disclosed embodiments.

Furthermore, one or more of the steps of the computer programs may be performed in parallel rather than sequentially. Such computer programs may be stored on any computer readable medium. The computer readable medium may include storage devices such as magnetic or optical disks, memory chips, or other storage devices suitable for interfacing with a general purpose computer. The computer readable medium may also include a hard-wired medium such as exemplified in the Internet system, or wireless medium such as exemplified in the GSM mobile telephone system. The computer programs, when loaded and executed on such a general-purpose computer, effectively result in an apparatus that implements the steps of the disclosed methods.

As previously stated, embodiments of the systems 100, 200 may also be implemented as hardware modules. More particularly, in the hardware sense, a module is a functional hardware unit designed for use with other components or modules. For example, a module may be implemented using discrete electronic components, or it can form a portion of an entire electronic circuit such as an Application Specific Integrated Circuit (ASIC). Numerous other possibilities exist. Those skilled in the art will appreciate that the system can also be implemented as a combination of hardware and software modules.

The host system 330 and remote systems 340, 370 may be similar to a computer system 700, schematically shown in Figure 7. They may be implemented as software, such as computer programs being executed within the computer system 700, and instructing the computer system 700 to conduct the methods of the example embodiments. Similarly, portions of the computer system 700 may be embodied in the disclosed systems 100, 200.

The computer system 700 can include a computer module 702, input modules such as a keyboard 704 and mouse 706 and a plurality of output devices such as a display 708, and printer 710.

The computer module 702 can be connected to a computer network 712 via a suitable transceiver device 714, to enable access to e.g. the Internet or other network systems such as Local Area Network (LAN) or Wide Area Network (WAN).

The computer module 702 in the example includes a processor 718, a Random Access

Memory (RAM) 720 and a Read Only Memory (ROM) 722. The computer module 702 also includes a number of Input/Output (I/O) interfaces, for example I/O interface 724 to the display 708, and I/O interface 726 to the keyboard 704. The components of the computer module 702 typically communicate via an interconnected bus 728 and in a manner known to the person skilled in the relevant art. The application program can be supplied to the user of the computer system 700 encoded on - a data storage medium such as a CD-ROM or flash memory carrier and read utilizing a corresponding data storage medium drive of a data storage device 730. The application program is read and controlled in its execution by the processor 718. Intermediate storage of program data maybe accomplished using RAM 720.

Embodiments of the present invention have several advantages over the prior art. For example, if a user loses the PortableUSB, or if the PortableUSB is stolen, the user can remove the relevant HomeUSB (identified using, for example, the physical markings on the HomeUSB). This prevents the possessor of the PortableUSB from utilizing/accessing resources at the home subnet. Since the paired HomeUSB and PortableUSB may be physically identifiable by their colour/physical markings, this step need not involve any software.

Additionally, there might be circumstances in which the user might not have physical access to the host system, e.g. while travelling. The system provides the capability to revoke the system pairing between the HomeUSB and the PortableUSB using the trusted third-party server. When a system pairing is registered with the trusted third-party server (during initialization), the trusted third-party server assigns a unique human-friendly randomly chosen revocation code to the system pairing. The revocation code can be stored separately from the HomeUSB 210 and PortableUSB 220. The user can store the revocation code in various ways, for example, in a mobile phone, computer, trusted third- party server, etc. The revocation code can take different forms. In one embodiment, the user may then send (from a pre-registered mobile number, preferably user's mobile number) this revocation code through SMS to the trusted third-party server. Alternately, a byte string may be sent from a pre- registered email address/chat account. In some embodiments, the user can revoke the system pairing from the remote system. This is possible as long as the user possesses the revocation code to revoke the system pairing.

It is understood that the user is expected to securely store this revocation code, for example, on their mobile phone, etc. When the user detects a loss of the PortableUSB, they can revoke the current system pairing by presenting the revocation code to the trusted third-party server. Once the trusted third-party server has received a revocation code and revoked a system pairing, any fresh requests for the HomeUSB address will not be entertained for that particular system configuration. Similarly, the trusted third-party server may also inform the HomeUSB that the current configuration of the system has been revoked and any existing VPN connection should be terminated. If a thief has already gained access to the host system before the revocation, once a revocation notice has been received, the host system will refuse to entertain requests from the stolen PortableUSB, even though the PortableUSB has already obtained host system's network address.

In other embodiments, the trusted third-party server can also generate a digitally signed list of revoked third-party pairings, similar to a certificate revocation list, and periodically publish it. Some embodiments of the system- of the -present- invention -allow a use o-insert-the system — into a standard USB port. As previously discussed, many other alternate connection methods are also available. Once the network configuration is completed on the host computer with both HomeUSB and PortableUSB attached to the host computer, the user removes the PortableUSB of the system, leaving behind the HomeUSB unit on the host computer. The user then carries the PortableUSB to any remote location. At that location, the user inserts the PortableUSB into a standard USB port. The host computer can be accessed like any other computer on a private subnet. No passwords are required. No difficult set-up is necessary. No additional software is required to be installed by the user. The entire process is performed seamlessly as far as the user is concerned, and the potential for the loss of confidential information is greatly reduced, if not virtually eliminated. All key management functions are handled automatically by the installed software without user intervention of any kind.

The cryptographic keys can be inserted onto the chips resident in the HomeUSB and PortableUSB. The chips may be tamper resistant. The keys that are generated on these chips never leave the chips. The HomeUSB and PortableUSB may share common external markings that are also coded into the chips. This prevents unauthorized access to data, and confusion for the user who possesses multiple systems. If a PortableUSB is inadvertently paired with an incompatible HomeUSB, the system may be prevented from working. Alternately, the system will work, but all information currently on both the HomeUSB and PortableUSB is deleted, and new keys are generated.

Figure 10 shows a flow chart 1000 illustrating a method for forming a virtual private network (VPN) between a host system and a remote system via a data link according to an example embodiment. At step 1002 a first module and a second module initially connected to each other are provided. At step 1004, the first module is connected to the host system. At step 1006, the first module and the second module are associated with each other. At step 1008, the second module is disconnected from the first module. Upon connecting the removed second module to the remote system, at step 1010, the VPN is formed between the host system and the remote system for accessing the host system via the data link.

It will be appreciated by a person skilled in the art that numerous variations and/or modifications may be made to the present invention as shown in the specific embodiments without departing from the spirit or scope of the invention as broadly described. The present embodiments are, therefore, to be considered in all respects to be illustrative and not restrictive.

Claims

1. A method for forming a virtual private network (VPN) between a host system and a remote system via a data link, the method comprising:

providing a first module and a second module initially connected to each other;

connecting the first module to the host system;

associating the first module and the second module with each other;

disconnecting the second module from the first module; and

upon connecting the removed second module to the remote system, forming the VPN between the host system and the remote system for accessing the host system via the data link.

2. The method as claimed in claim 1 , wherein the step of forming the VPN between the host system and the remote system comprises:

obtaining a network address of the host system;

mutually authenticating the first module and the second module; and

securely connecting the remote system to the host system via the data link.

3. The method as claimed in claim 1 or 2, wherein the host system is disposed in a first subnet, and accessing the host system comprises accessing resources on said first subnet.

4. The method as claimed in any one of the preceding claims, further comprising:

sending information from the host system to the remote system via the data link; and separating information destined for the remote system using a virtual network interface.

5. The method as claimed in claim 2, wherein the step of automatically forming the VPN between the host system and the remote system further comprises configuring the remote system to be accessible by the host system, thereby forming a bidirectional VPN.

6. The method as claimed in claim 5, wherein the remote system is disposed in a second subnet, and accessing the remote system comprises accessing resources on said second subnet.

7. The method as claimed in claim 6, further comprising installing a network address translator (NAT)-type system in each of the host system and remote system for routing traffic between the first subnet and the second subnet.

8. The method as claimed-in-elaim-6 - or- 7_r wherein -the host system -and- the-remote - system can be accessed simultaneously if the first and second subnets have non-overlapping address ranges.

9. The method as claimed in any one of claims 3 to 8, wherein the resources comprise one or more of a group consisting of Windows file sharing, client-server applications, network printers, Internet access and web-based applications.

10. The method as claimed in any one of the preceding claims, further comprising routing the data link through a trusted third party server.

11. The method as claimed in claim 10, further comprising providing a firewall between the third party server and at least a respective one of the host and remote systems.

12. The method as claimed in any one of the preceding claims, wherein the first and second modules comprise USB modules and connecting the first and second modules to the host and remote systems comprises connecting to respective USB ports.

13. The method as claimed in any one of the preceding claims, wherein the first and second modules are interchangeable.

14. The method as claimed in any one of the preceding claims, wherein the host system comprises one system of a plurality of systems, and wherein the first module is movable to any other system of the plurality of systems, for forming a VPN between said other system and the remote system.

15. The method as claimed in any one of the preceding claims, further comprising encrypting all data between the host system and the remote system using a hardware key.

16. An access system for forming a virtual private network (VPN) between a host system and a remote system via a data link, the access system comprising:

a first module and a second module, the first and second modules being associated with each other; wherein:

the first module is capable of being connected to the host system and the second module; and -the second module is capable -of being- disconnected from the first module, -and connected- to - .. the remote system such that the VPN is formed between the host system and the remote system for accessing the host system via the data link.

17. The access system as claimed in claim 16, where the first module and the second module are associated with each other and with the host system.

18. The access system as claimed in claim 16 or 17, further configured to obtain network address of the host system; mutually authenticate the first module and the second module; and securely connect the remote system to the host system via the data link, for forming the VPN between the host system and the remote system.

19. The access system as claimed in any one of claims 16 to 18, wherein the host system is disposed in a first subnet, and resources on said first subnet are accessible via the host system.

20. The access system as claimed in any one of claims 16 to 19, further comprising means for sending information from the host system to the remote system via the data link, wherein information destined for the remote system is separated using a virtual network interface.

21. The access system as claimed in claim 19, wherein the remote system is configured to be accessible by the host system such that a bidirectional VPN is formed between the host system and the remote system.

22. The access system as claimed in claim 21 , wherein the remote system is disposed in a second subnet, and resources on said second subnet are accessible via the remote system.

23. The access system as claimed in claim 22, further comprising a network address translator (NAT)-type system installed in each of the host system and remote system for routing traffic between the first subnet and the second subnet.

24. The access system as claimed in claim 22 or 23, wherein the host system and the remote system can be accessed simultaneously if the first and second subnets have non-overlapping address spaces.

-25. The access system-as-claimed in any one- of claims-19 to-24,-wherein the-resources- comprise one or more of a group consisting of Windows file sharing, client-server applications, network printers, Internet access and web-based applications.

26. The access system as claimed in any one of claims 16 to 25, wherein the data link is routed through a trusted third party server.

27. The access system as claimed in claim 26, further comprising a firewall between the trusted third party server and at least a respective one of the host and remote systems.

28. The access system as claimed in claim 26 or 27, wherein the third party server is disposed in a cloud network.

29. The access system as claimed in any one of claims 16 to 28, wherein the first and second modules comprise USB modules and the host and remote systems comprise respective USB ports for receiving the first and second modules.

30. The access system as claimed in any one of claims 16 to 29, wherein the first and second modules are interchangeable.

31. The access system as claimed in any one of claims 16 to 30, wherein the host system comprises one system of a plurality of systems, and wherein the first module is movable to any other system of the plurality of systems, for forming a VPN between said other system and the remote system.

32. The access system as claimed in any one of claims 16 to 31 , further comprising a hardware key for encrypting all data between the host system and the remote system.

33. A VPN formed using the method as claimed in any one of claims 1 to 15.

34. A computer readable medium having stored thereon computer code means to instruct a computer to execute a method of forming a virtual private network (VPN) between a host system and a remote system via a data link, the method comprising:

providing a first module and a second module initially connected to each other

connecting the first module to the host system;

associating the first module, the second module and the host system with each other; disconnecting the second module-from-the first-module; and- upon connecting the removed second module to the remote system, forming the VPN between the host system and the remote system for accessing the host system via the data link.