Introduction

The ViPNet technology is designed for deployment of protected VPNs over global and local networks. It facilitates the transparent interaction of protected computers, independently from their location, IP address or the way they are connected to a network. The interaction can be established on the basis of client-to-client, client-to-site and site-to-site (ViPNet tunnel) schemes.

The main difference between the ViPNet technology and most modern ViPNet systems mainly designed to establish protected connection between local networks and to provide remote access to their resources, is the use of special dynamic routing protocols for ViPNet traffic. These protocols ensure secure exchange of ViPNet hosts through a ViPNet gateway or directly.

For channel protection, ViPNet provides a proprietary ViPNet. It can implement different encryption protocols, including AES. For building a ViPNet, ViPNet uses symmetric keys, which helps to avoid periodic sessions for network host authentication and session key generating. Required in systems with public key distribution, these operations affect the use of ViPNet in local networks and reduce the interference immunity of sessions because a session may be disrupted at the synchronization stage. In the ViPNet network, you do not need to deploy a complicated PKI infrastructure required for using an asymmetric key structure securely.

In the ViPNet technology, as opposed to most modern ViPNet technologies which also allow you to work with symmetric keys, there is an automated system for symmetric key management.

ViPNet provides ViPNet-to-IPsec gateways, which allow hosts protected with ViPNet to communicate with hosts tunneled by a remote IPsec gateway, as well as remote IPsec clients.

ViPNet network A connected with partner ViPNet network B.

Managing Keys and Creating Network Logical Structure

ViPNet hosts, links and keys

In a protected ViPNet network, hosts are identified by a unique ViPNet ID. ViPNet hosts can communicate over encrypted channels, if there is a link between them in a protected ViPNet network. Host links are set in the ViPNet Administrator software. Setting or deleting links in a ViPNet network allows administrator to manage its logical topology. For example, ViPNet network administrator can separate a network into sections and control user access. For each link, there is a separate symmetric key for encrypted communication of the two linked hosts. When two hosts get linked, the key is generated.

At a ViPNet host’s initial installation, the administrator creates a ‘key set’, a package including address book and set of keys, which has to be delivered to the host and deployed. After that, keys and information about host links is updated on hosts from ViPNet Administrator at each change in topology, host settings, and in some other cases.

Hosts protected with ViPNet

ViPNet Client provides security of a computer by the following:

• ViPNet Client connects a computer, mobile device, and other types of network hosts to a ViPNet, independently of how they connect to your network infrastructure. This feature provides traffic encryption.
• ViPNet Client has an integrated personal ViPNet firewall that ensures protection of a host when it establishes connection to another host within its ViPNet, as well as to an unprotected host. The firewall can have different rules set for the encrypted and unencrypted traffic.

ViPNet Coordinator provides network security by the following:

• functions as a ViPNet gateway to connect unprotected computers and other network devices to a ViPNet, organizes communication between of ViPNet clients and tunneled hosts.
• has an integrated ViPNet firewall that provides protection of LANs (when a coordinator is placed on the edge of a LAN). A coordinator can perform NAT.
Coordinators have software, appliance and virtual appliance implementations.

Tunneled hosts are the hosts that do not have any ViPNet software for building ViPNet connections and that use a coordinator as a ViPNet gateway.

Symmetric Keys in ViPNet

In the ViPNet software, the following symmetric keys are used (see the figure below):

Exchange keys are used for traffic encryption on the network layer between hosts.
• Encryption is performed using the keys derived from exchange keys. Encryption keys are unique for each IP packet.
• Each pair of ViPNet hosts that have connection in ViPNet network has a separate exchange key.
• Exchange keys are distributed centrally from ViPNet Administrator to appropriate ViPNet hosts. This is done in cases of changes in network topology, scheduled keys’ change, and hosts’ keys compromise. Being stored on ViPNet hosts, these keys are encrypted using special protection keys.

Protection keys of exchange keys are used for organizing interaction between ViPNet Administrator and all other hosts of the ViPNet network on the application layer. These keys are used for encryption of exchange keys. Being stored on ViPNet hosts, these keys are encrypted using special protection keys.

Protection keys of exchange keys are used for organizing interaction between a ViPNet host with ViPNet Administrator and all other hosts of the ViPNet network on the application layer. These keys are used for encryption of exchange keys. Being stored on ViPNet hosts, these keys are encrypted using special protection keys.

Personal keys are used for separating the access of several users on the same host to various data. These keys are used for encrypting the protection keys of exchange keys, as well as other personal information of an individual user. You can store personal keys on an external device as well as on your ViPNet host. When stored, personal keys are encrypted using the user password key.

A password key is a byte sequence received by calculating the user password’s hash function value. A password key is used for encrypting personal keys of each user. Password keys can be generated in ViPNet Administrator or by a user on a ViPNet host. Password keys are generated as often as required, for temporary usage, and are not stored on devices.
A password is a sequence of alphanumeric symbols from 9 to 32 bytes long. Passwords can be generated in the ViPNet Administrator program, or by a user on a ViPNet host. If an external device protected with a PIN code (a SmartCard) is used, you can use a PIN code instead of a password.

Updating Keys and Host Links

If in ViPNet Administrator you have changed the ViPNet network structure or ViPNet host options, transfer information about those changes to ViPNet hosts by sending keys and host links updates. Symmetric keys distribution is fully automated and requires no additional user operations.

You need to create host keys in the following cases:

• ViPNet hosts or users have been added or deleted.
• Links between hosts or users have been edited.
• Users have been added to or removed from hosts.
• Users have been added to or removed from a group.
• A client's transport server has been changed.
• You need to update only host links in all other cases, for example:
• Roles have been assigned to or removed from hosts; role properties have been changed.
• Host addresses have been changed.
• Parameters of connecting hosts to an external network have been changed.

Principles of Establishing Connections on a ViPNet Network

ViPNet clients can automatically establish connections to other ViPNet hosts over the shortest accessible routes. They use connection servers to establish communication. Clients receive information about other hosts, their access parameters, and status from their IP addresses servers. Clients detect connection parameters automatically by using connection servers.

Each coordinator receives information about other hosts from other coordinators it is linked with. Coordinators may connect to an external network in one of the following ways:

• Connecting to an external network directly.
• Connecting a coordinator through another coordinator.
• Connecting via a firewall with dynamic NAT.
• Connecting via a firewall with static NAT.

Client-to-client connections are established in the following way:

• Before a client initiates connection to another host, it should detect the access channel to its connection server. If the client communicates through a NAT device, it maintains the channel with the connection server by periodically sending IP packets to it. By default, IP packets are sent each 25 seconds. With most NAT devices, it is usually sufficient to stay connected to the connection server. If necessary, you can modify the frequency.
• After connection between the client and its connection server is established, the client initiates connection to another host. It starts transferring test IP packets to a remote host via the connection server. At the same time, the client sends test IP packets to the connection server of the remote host and directly to the remote host.
• If the test IP packets are received on the remote host, the remote host registers the connection and begins to transfer response IP traffic directly. The client receives the response IP traffic from the remote host and begins to transfer its IP traffic to the remote host directly, too.

If the test IP packets pass only till the remote host's connection server, the connection server registers this connection and sends the response IP packets of the remote host to the client directly.

In other words, the client establishes either direct connection with the remote host, or via the remote host's connection server. If the client receives no response IP packets from the remote host or its connection server, communication goes on through the client's connection server.

Thus, the ability to communicate over the shortest routes without coordinators' participation increases encrypted IP traffic exchange rate and reduces the load on coordinators.

Moreover, ViPNet connections have the following peculiarities:

• If routing is configured for hosts, then connection between clients will be established in compliance with the routes through the gateways, but not coordinators.
• If the remote host does not use a NAT device, the client's connection server remembers that the connection can be established directly. So, next time, if the remote host's location has not changed, test IP packets will not be sent, and the IP traffic exchange is performed directly at once.
• If clients are located behind devices with dynamic NAT, they can communicate directly. This is possible due to the ability of connection servers to inform clients about IP addresses and ports, by which they can access other hosts via NAT devices. The servers detect this data by the IP packets received from clients.

Taking this information into account clients send test IP packets to each other using registered IP addresses and ports. If at least one side receives the test IP packets, the clients begin to exchange all their traffic directly. In other words, direct connection will be established if at least one NAT device allocates one port for a host each time this hosts sends IP packets to different IP addresses.

Direct communication between clients is impossible if their NAT devices allocate ports randomly each time IP packets are sent from new IP addresses. That is how the so-called symmetric NAT works. In this case, connection between such clients will be established through one of their connection servers.

• Direct connection to the remote client located behind a device with dynamic NAT is possible within 75 seconds (three timeouts or periods of IP packets sending) since the last connection was broken.
• If a client is behind a static NAT device, you need to fix the required UDP packets encapsulation port in the program options. Otherwise, the port will be changed preventing the client from connecting to other hosts.

ViPNet Coordinator's Roles

On a ViPNet network, a coordinator functions as a ViPNet server. Depending on the tasks that should be performed on your corporate ViPNet network, on the network structure, and other conditions, a ViPNet coordinator may perform one or several of the following functions:

• A ViPNet server (IP address server), which gathers ViPNet hosts' status information and notifies its clients about other hosts' statuses and access parameters of other clients (also called “an IP addresses server”).
• A ViPNet packets router, which ensures routing of unencrypted traffic passing through the coordinator to other protected hosts (so-called “forward unencrypted traffic”).
• A stateful firewall, which tracks the state of network connections and is able to hold significant attributes of each connection in memory, from start to finish. It performs network addresses translation (NAT) for forward unencrypted traffic as well.
• A ViPNet gateway (tunneling server). You can use a coordinator to ensure traffic encryption for unprotected hosts within potentially insecure network segments.
• A transport server, which ensures the delivery of keys and host links updates created in ViPNet Administrator to ViPNet hosts, as well as the possibility to send ViPNet software upgrades centrally from ViPNet Administrator.
• A TCP Tunnel server. Allows clients to communicate with other ViPNet clients on external networks in case the UDP protocol is blocked by the Internet provider.
• An IPsec gateway, which allows the interaction of ViPNet hosts with remote hosts and networks over IPsec ViPNet channels.
• An L2 ViPNet gateway, which allows you to connect two or more LANs into a network with direct visibility at the layer 2 (OSI).

IP Addresses Server

When a ViPNet Client connects to the protected network or changes connection parameters, it reports its status and changes to the coordinator that functions as an IP addresses server for this client. In return, the IP addresses server informs the client about statuses and connection parameters of ViPNet hosts this client is linked with.

Thus, an IP addresses server performs the following tasks:

• collects information about ViPNet hosts;
• informs each client that uses this IP addresses server about access parameters of the ViPNet hosts this client is linked with.

   

A ViPNet client connected to the private network confirms its status by sending messages to its IP addresses server in certain time intervals (5 minutes by default). If the IP addresses server does not receive such messages, it changes the client's status to “Unreachable.”

Coordinators inform each other about their access parameters in the same manner. A coordinator periodically (every 15 minutes, by default) confirms its status to other coordinators it has links with. Besides, coordinators that function as IP address servers exchange information about their clients, taking into account links, or associations, set between clients.

An IP addresses server functions as follows:

• When your coordinator receives some new data about its client (a client that uses this coordinator as an IP addresses server), it forwards this data to its other clients and to the coordinators it is linked with.
• When your coordinator receives new data about clients of other coordinators, it forwards this data to its clients that are connected with other coordinator's clients.
• If the IP addresses server does not receive any data about its client at the end of the polling period, it considers this client to be unreachable and sends this information to other hosts.
• If a coordinator on your ViPNet network communicates with another ViPNet network, it informs the gateway coordinator of that network about the state of all your ViPNet hosts linked with another network hosts. The gateway coordinator receives this information and forwards it to all coordinators on that ViPNet network and to its clients that have links with your network hosts.

In ViPNet Administrator, every client is assigned to some coordinator that functions as its IP addresses server.

ViPNet Packets Router

A coordinator routes forward encrypted traffic, transferring it to other protected hosts. The routing is performed within a ViPNet network, as well as when interacting with other ViPNet networks.

Encrypted traffic is routed based on the ViPNet host identifiers specified in the unencrypted part of IP packets, which is protected against falsification. The routing is performed over a proprietary protocol designed for secure dynamic routing of traffic. Along with the routing, network address translation (NAT) is performed for encrypted traffic. All forward encrypted packets that are received by a coordinator are sent to other hosts with the coordinator's IP address as their source IP address. NAT for encrypted traffic is performed automatically, according to the parameters that you cannot change.

If a third-party device, filtering and translating the transferred traffic, is set on the edge of a ViPNet network, the coordinator can function as a connection server. Clients establish communication with each other via a connection server only if they cannot establish a direct connection. You can specify different connection servers for different clients. By default, a client's connection server is the same as its IP address server.

Firewall

The coordinator can filter any IP packets on each network interface by addresses, protocols, and ports in accordance with the network filters. With network filters, you can block unwanted connections as well as allow connections with unprotected hosts located outside of the ViPNet network.

Along with the user-defined network filters, ViPNet Administrator offers an anti-spoofing system. This system protects your computer from a common network attack.

A coordinator may be located on the edge of a local network and function as a firewall for protected and unprotected hosts, as well as translate network addresses for unencrypted traffic that passes through the coordinator.

NAT for unencrypted traffic allows you to configure rules for the two main purposes:

• Connect a local network to the Internet in case the number of the local hosts is greater than the number of public IP addresses allocated by the Internet provider. Thus, NAT allows hosts that have private IP addresses to access the Internet using the coordinator's public IP address.
• This is possible due to the source address translation.
• To provide public network hosts with access to private network hosts. As a result of using the NAT technology, Internet users can access local network hosts by public IP addresses, even though private addresses are used in the local network.

This is possible due to the destination address translation.

ViPNet Gateway

A ViPNet gateway feature allows you to include unprotected hosts into a protected ViPNet network without installing ViPNet software on those hosts. You can also protect connections with unprotected hosts when data is transferred via the Internet or other public networks. This is possible due to the tunneling technology.

The tunneling consists in unprotected hosts' traffic encryption, which is carried out by the coordinator functioning as the host's ViPNet gateway. With the tunneling technology, you can establish a protected connection between an unprotected host and a protected ViPNet host or between two unprotected hosts that are tunneled by two different coordinators.

The tunneling technology allows you to protect the traffic between the hosts, on which you cannot install the ViPNet Client or the ViPNet Coordinator software (for example: a server, a network printer, a network-attached storage, and so on).

When tunneled, the unprotected host's traffic is protected in the following way:

• Unprotected IP packets are transferred from the tunneled host to a coordinator.
• On the coordinator, the IP packets get processed by network filters, encrypted, and transferred to the protected host, to which these packets are addressed, or to a different coordinator.
• If a coordinator receives encrypted IP packets addressed to a tunneled host, then these packets are processed by network filters, unencrypted, and transferred to the destination host.

 

Transport Server

In ViPNet Administrator, every newly created host is assigned a coordinator as its transport server. A transport server ensures the delivery of service information, keys and host links updates, software upgrades, which are sent centrally from ViPNet Administrator to hosts, and the exchange of application and transport envelopes between hosts.

Application and control envelopes are routed by the ViPNet MFTP transport module, which operates on the application layer. On a coordinator, the transport module receives envelopes from other ViPNet hosts and forwards them to the destination host.

TCP Tunnel

On a coordinator, you can configure a TCP tunnel for communication between clients on external networks with other ViPNet clients in case the UDP protocol is blocked by the ISP when clients connect to external networks.

If a remote client cannot connect to other hosts over UDP and a TCP tunnel is configured on its connection server, it will establish connection to hosts over the TCP tunnel of the connection server. On the connection server, the received IP packets are retrieved from the TCP tunnel and transferred to destination hosts over UDP.

IPsec gateway
Coordinators (the ViPNet Coordinator HW or VA version) can work as IPsec gateways, providing communication of hosts in a ViPNet network:
• with hosts in a remote network protected with an IPsec gateway;
• with remote IPsec hosts (including iOS and Android mobile devices).

A coordinator can re-encrypt traffic between hosts protected with ViPNet and hosts protected with IPsec.

L2 ViPNet gateway

Coordinators (the ViPNet Coordinator HW or VA version) can provide connection of remote network segments at the layer 2 (OSI). This is implemented with Secure Cyber Circuits original L2OverIP technology. Ethernet frames are encapsulated into IP-packets and transferred over an encrypted ViPNet ViPNet connection.

The L2OverIP technology allows you to connect two or more remote LANs into a network with direct addressing at the 2nd layer.

Traffic Encryption and Filtering

Core of the ViPNet Technology: Kernel-Level ViPNet Driver

Principle of the ViPNet Driver Operation

The ViPNet driver is the core of the ViPNet technology. Its main functions are filtering, encryption and decryption of incoming and outgoing IP packets.

Each outgoing IP packet is processed by the ViPNet driver in one of the following ways:

• is encrypted and sent;
• is sent as is (unencrypted);
• is blocked (according to the network filters).

Each incoming IP packet is processed in one of the following ways:

• is allowed (if the packet is unencrypted and the filters
allow unencrypted traffic);
• is decrypted (if the packet was encrypted);
• is blocked (according to the network filters).

The ViPNet driver works between the data link and network layers of the OSI model, which allows processing IP packets before they reach the TCP/IP stack and, eventually, the application layer. Thus, the ViPNet driver protects IP traffic of all applications not affecting your usual workflow.

Due to this approach, introduction of the ViPNet technology does not require any changes in well-established business processes, and the ViPNet network deployment costs are not high.

The figure below demonstrates how the ViPNet driver participates in processing a request for viewing a web page. The web page is hosted by an IIS server installed on computer B.

Computer A requests computer B to display the web page over the HTTP protocol. This request is transferred to lower layers of the TCP/IP stack, and service information is added to this request in each of the layers. Then the ViPNet driver on computer A receives the request and encrypts it by adding its own information to the request. The ViPNet driver on computer B receives the request and removes service information from it. Then the ViPNet driver decrypts the request and sends it to the application layer via the TCP/IP stack for processing.

Traffic Filtering by the ViPNet Driver

Each outgoing packet is processed by the ViPNet driver according to one of the following rules:

• If a packet is not to be encrypted, it is either blocked or sent to the network without encryption according to filtering rules for public network. If required, NAT is performed by the Coordinator.
• If a packet is to be encrypted, it is either blocked or sent to the network with encryption according to filtering rules for ViPNet network. If required, NAT is performed by the Coordinator.
• After processing by a ViPNet driver, the original IP packet addressed to a protected host becomes encrypted. A new IP packet is formed which consists of the encrypted original IP packet, public identifying header and private service headers protected with the message authentication code, and
headers of the new IP packet.

Each incoming packet is processed in the following way:

• Unencrypted packets received from unprotected hosts are blocked or passed in accordance with the filtering rules for public network. An unencrypted packet received from a protected host is blocked as potentially false.
• Encrypted packets addressed to this host (according to its ID) are decrypted, blocked or translated (according to the filtering rules for ViPNet network specified above), and forwarded to the TCP/IP stack.
• If an encrypted packet addressed to another host (according to the packet's ID) is received by a Coordinator, the packet is not decrypted, and IP addresses and ports of the ViPNet packet are substituted in accordance with the relevant information about the nearest point of access to the destination host. The packet is forwarded to the network through a Coordinator interface, which is most suitable for packet transmission to the destination host according to the routing tables.

Processing the incoming packets

Processing the outgoing packets

Architecture

The ViPNet technology provides cryptographic functions at the application level as well as at the OS kernel level.

Channel encryption

At the OS kernel level, IP packet encryption is implemented by the cryptographic driver ITCSCrpt.

For encryption, the ITCSCrpt driver can utilize different modules implementing cryptographic algorithms. The cryptographic modules are accessed over standardized interfaces. In this way, the module implementing symmetric AES-256 (FIPS 140-2 certified) is implemented and available.

This architecture allows you to implement modules that provide a variety of cryptographic algorithms, at a low cost. The modules can be either software- or hardware-based.

Application-level encryption and key management

Application level provides user authentication, loading keys to the cryptographic driver, data encryption and key update.

For cryptographic functions, Microsoft CryptoAPI 2.0 universal interfaces are used. For OS other than Windows, a similar interface and technology of interaction with cryptographic provider is implemented. This technology provides the transparent enabling of a variety of cryptographic algorithm implementations. Currently, AES-256 module is available. Any cryptographic module can be used, including modules of other vendors utilizing standard cryptographic service provider (CSP) interface.