How does cipherscale work?

Cipherscale has four functional elements, excluding the website. The website allows one to sign up and log in to the cipherscale Administration Portal. The four functional elements are:

Administration Portal (hosted and managed by cipherscale) - The web portal from which the Owner or Administrator configures and manages the cipherscale space. The Administration Portal and the Controller are clustered together in various geographical regions to account for data sovereignty, compliance, and other regional requirements.
Controller (hosted and managed by cipherscale) - This is the intelligence that controls the workings of cipherscale. It is a multi-tenant service and is the control plane between the devices and the Gateways. A few key functions it performs are:

- Policy Decision Point (PDP): It determines whether to grant access to the cipherscale space resources or not based on the admission rules and access policies configured by the Administrator. It then controls the Gateway accordingly and sets up firewall rules. The Gateway behaves as the Policy Enforcement Point (PEP).
- DNS proxy: The devices request DNS resolutions from the Controller securely over gRPC. The Controller obtains the resolution from the Gateway responsible for providing access to the destination.
- Gateway selection: When multiple Gateways provide access to the same resource, the Controller chooses one or more Gateways based on the round-trip-time from the device and the load distribution policy set by the cipherscale space Administrator.
- WireGuard control plane: The Controller communicates with the devices and Gateways and distributes the peer and key information needed for establishing WireGuard connections.
- Log storage: The Controller stores audit logs of admin portal activity and other logs unrelated to usage. The usage logs are stored locally in the Gateways.

Gateway (hosted and managed by the customer): The Gateway is the Policy Enforcement Point (PEP). The Gateway and the devices that communicate with it form the data layer. The Gateway software must be installed on the network that provides the services for the devices to access. The key functions that a Gateway performs are:

- It terminates the end-to-end WireGuard tunnel from the devices.
- It resolves DNS queries relayed to it by the Controller using its locally configured DNS server and relays the responses back.
- It acts as a software router by routing traffic between the WireGuard and local interfaces and carrying out NAT.
- It implements firewall rules to enforce the policies communicated by the Controller.
- It collects and stores logs.

App (installed on devices by the customer): The cipherscale application must be installed on devices that need to use cipherscale. The application allows the device to establish tunnels to one or more Gateways simultaneously as directed by the Controller. It also performs the following key functions:
- Provide location and device attributes to the Controller during session start, regularly thereafter, on change, and on demand.
- Calculate performance metrics to the various Gateways and provide them to the Controller for Gateway selection.
- Send all DNS requests to Controller over HTTPS.

To get a better understanding of how it all works. Let us consider an example. The Admin has configured a private resource, a SaaS application, and three Gateways by using the Administration portal as follows:

Private resource: A private application called privateapp.local running on a server at 192.168.1.10. The DNS record for privateapp.local is configured on a private DNS server running on 192.168.1.1. The Gateway is deployed on the private network and has a private IP of 192.168.1.11 and a public IP of 173.70.130.198. The Gateway’s DNS server is configured as 192.168.1.1

SaaS application: One Gateway is deployed in California with a public IP of 66.249.68.32; another is in Boston at 146.75.252.1. Both provide access to the SaaS application saasapp.com. Both Gateways are configured to use Google DNS servers 8.8.8.8

Access Policy: The access policy is configured to provide the Admin access to all private resources and SaaS applications and is associated with the Admission Rule below.

Admission Rule: An Admission rule is configured to admit access only if the user's location is in the USA.

Here are the steps that the device, located in Boston, takes after the admin signs in using the cipherscale app and tries to access privateapp.local and saasapp.com

The device sets up a control channel over HTTPS to the cipherscale Controller.
The device gathers device posture and location information and sends it to the Controller. Note: The device will periodically send this information, send on detecting change, or when requested by the Controller.
The device receives the IP addresses of the Gateways (66.249.68.32, 146.75.252.1, 173.70.130.198) associated with authorized applications from the Controller and a request to calculate the round trip time (RTT) to them.
1. The device responds with the RTT to all the provided Gateways. Note: The device will provide updates to the RTT regularly or at the Controller's request.
The device sets up a secure control session to the Controller and forwards all DNS requests to the Controller.
The device forwards the DNS request for privateapp.local to the Controller when the user tries to access it.
1. The Controller checks the admission rule and access policy. All checks pass.
2. The Controller then forwards the DNS request to the Gateway providing access to privateapp.local
3. The Gateway resolves the DNS request using the local 192.168.1.1 DNS server and responds with 192.168.1.10 to the Controller.
4. The Controller provides the Gateway with the information needed for a P2P WireGuard tunnel to the device and to configure firewalls.
5. The Controller provides the device with the DNS response and the information needed for a WireGuard tunnel to the Gateway. It adds 192.168.1.10 as the AllowedIP for the tunnel to the Gateway.
The device sets up a WireGuard connection to the Gateway with the information received from the Controller.
The device receives traffic to 192.168.1.10, which it routes to the Gateway over the WireGuard connection.
1. The Gateway routes the request to the destination and acts as a router to facilitate communication.
The device receives a DNS request for google.com, which it forwards to the Controller.
1. The Controller sees that it is not a resource associated with the cipherscale space and provides a response of 142.250.65.174 by using a public DNS server.
The device gets traffic destined to 142.250.65.174, which it routes through its local interface because it does not match any of the AllowedIP for WireGuard connections.
The device receives the DNS request for saasapp.com when the user tries to access it, which it forwards to the Controller.
1. The Controller checks the admission rule and access policy. All checks pass.
2. As two Gateways provide access to the app, the Controller uses the RTT that the device provided earlier and chooses the Boston Gateway.
3. The Controller then forwards the DNS request to the Boston Gateway.
4. The Gateway resolves the DNS request using the configured DNS server 8.8.8.8 and responds with 140.250.0.180 to the Controller.
5. The Controller provides the Gateway with the information needed to establish a P2P WireGuard tunnel to the device and configure firewalls.
6. The Controller provides the device with the DNS response and the information needed for a WireGuard tunnel to the Gateway. It adds 140.250.0.180 as the AllowedIP for the tunnel to the Gateway.
The device sets up a WireGuard connection to the Boston Gateway. Note that the device now has two simultaneous WireGuard connections: one to the Gateway for the privateapp.local and another to the Boston Gateway for saasapp.com.
The device receives traffic to 140.250.0.180, which it routes to the Boston Gateway over the WireGuard connection.
1. The Gateway employs NAT and routes the request to the destination. The servers for saasapp.com receive traffic with the Gateway’s IP address 146.75.252.1 as the source IP.