Private and permissioned onion routing network

Abstract

A private onion routing network comprises network nodes communicatively coupled by network(s), the network nodes comprising: relay nodes; hidden services directory node(s); hidden service node(s); rendezvous point node(s). The hidden services directory node(s) is configured to: receive identity information and an onion address for a hidden service from a client computing device across the network(s); verify that the identity information received from the client computing device is associated with permissions to access the hidden service identified by the onion address; and communicate a descriptor for the hidden service to the client computing device across the network(s), wherein the descriptor includes a rendezvous address for a rendezvous point node of the rendezvous point node(s), wherein the rendezvous point node is where the client computing device meets with the hidden service node(s).

Description

PRIVATE AND PERMISSIONED ONION ROUTING NETWORKCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of United States Provisional Patent Application Serial No. 63 / 580,883, filed on September 6, 2023 and entitled “PRIVATE SELF-HOSTED ONION ROUTING”, which is hereby incorporated herein by reference in its entirety.BACKGROUND

[0002] Internet protocol (IP) data can be used to communicate data between computing devices across networks.SUMMARY

[0003] A private onion routing network comprises a plurality of network nodes communicatively coupled by at least one network, the plurality of network nodes comprising: a plurality of relay nodes; at least one hidden services directory node; at least one hidden service node; at least one rendezvous point node. The at least one hidden services directory node is configured to: receive identity information and an onion address for a hidden service from a client computing device across the at least one network; verify that the identity information received from the client computing device is associated with permissions to access the hidden service identified by the onion address; and communicate a descriptor for the hidden service to the client computing device across the at least one network, wherein the descriptor includes a rendezvous address for a rendezvous point node of the at least one rendezvous point node, wherein the rendezvous point node is where the client computing device meets with the at least one hidden service node.

[0004] A system comprises a computing device configured to: receive an onion address for a hidden service from a user; communicate identity information and the onion address for the hidden service to a hidden service directory node across at least one network to verify existence of a hidden service node associated with the hidden service; receive a descriptor for the hidden service from the hidden service directory node across the at least one network, wherein the descriptor includes a rendezvous address for a rendezvous point node where thecomputing device meets with the hidden service node; generate meeting rendezvous details using a one-time password and the rendezvous address of the rendezvous point node; communicate the meeting rendezvous details to at least one introduction point node received in the descriptor to establish the rendezvous point node to meet with the hidden service node; and receive the one-time password at the computing device from the hidden service node at the rendezvous point node.

[0005] A method for operating a private onion routing network comprises: receiving, by a hidden services directory node of the private onion routing network, identity information and an onion address for a hidden service from a client computing device across at least one network; verifying, by the hidden services directory node, that the identity information received from the client computing device is associated with permissions to access the hidden service identified by the onion address; communicating, by the hidden services directory node, a descriptor for the hidden service to the client computing device across the at least one network, wherein the descriptor includes a rendezvous address for a rendezvous point node, wherein the rendezvous point node is where the client computing device meets with at least one hidden service node of the private onion routing network.

[0006] A method for operating a private onion routing network comprises: receiving, at a directory authority node of the private onion routing network, identity information from a client computing device across at least one network; verifying, by the directory authority node, that the identity information received from the client computing device is associated with permissions to access a consensus file; and communicate the consensus file from the directory authority node to the client computing device across the at least one network.

[0007] A method for operating a private onion routing network comprises: receiving, by a node of the private onion routing network, identity information from a client computing device across at least one network; verifying, by the node, that the identity information received from the client computing device is associated with permissions to access the private onion routing network; allowing communication from the client computing device within the private onion routing network.DRAWINGS

[0008] Understanding that the drawings depict only exemplary embodiments and are not therefore to be considered limiting in scope, the exemplary embodiments will be describedwith additional specificity and detail through the use of the accompanying drawings, in which:

[0009] Figures 1A-1C are block diagrams illustrating example systems for reaching consensus between directory authorities in a privately hosted onion routing network.

[0010] Figure 2 is a block diagram illustrating an example system for communication with a hidden service in a privately hosted onion routing network.

[0011] Figure 3 is a block diagram illustrating an example circuit for circuit encryption within a privately hosted onion routing network.

[0012] Figure 4 is an example method for creating hidden service(s).

[0013] Figure 5 is an example method for obtaining a consensus fde at a client computing device.

[0014] Figure 6 is an example method for accessing hidden service(s) from a client computing device.

[0015] Figure 7 is an example method for allowing access to hidden service(s) by client computing device(s).

[0016] Figure 8 is an example method for permissioning access to a private onion routing network by client computing device(s).

[0017] Figure 9 is an example of a computer system with which embodiments of the present disclosure may be utilized.

[0018] In accordance with common practice, the various described features are not drawn to scale but are drawn to emphasize specific features relevant to the exemplary embodiments.DETAILED DESCRIPTION

[0019] In the following detailed description, reference is made to the accompanying drawings that form a part hereof, and in which is shown by way of illustration specific illustrative embodiments. However, it is to be understood that other embodiments may be utilized and that logical, mechanical, and electrical changes may be made. Furthermore, the method presented in the drawing figures and the specification is not to be construed as limiting the order in which the individual steps may be performed. The following detailed description is, therefore, not to be taken in a limiting sense.

[0020] Onion routing networks are described in US Patent No. 6,266,704 (Reed et al.), which is herein incorporated by reference. In addition, the Tor network has implemented onion routing as described at the following webpages, which are each incorporated herein by reference: (1) https: / / metrics.torproject.org / glossarv.html; (2) https: / / support.torproject.org / glossary / ; (3) https: / / gitweb.torproject.org / torspec.git / tree / dir- spec.txt; (4) https: / / community.torproject.org / onion-services / overview / ; (5) https: / / communitv.torproject.org / onion-services / advanced / client-auth / ; (6) https: / / support.torproject.org / about / how-is-tor-different-from-other-proxies / ; and (7) https: / / support.torproject.org / .

[0021] Various technical problems are improved and / or solved by aspects of example systems and methodologies described herein. The following aspects are described in more detail below: (1) Identity (or Authentication) Implementation on an Onion Routing Network & Identity (or Authentication) Management for Hidden service(s) Access on a Private Onion Routing Network; (2) Technical Framework and Infrastructure for Building a Private Onion Routing Network; (3) Automated and Configurable Build and Deployment of a Private Onion Routing Network; (4) Use of a Hardware Device to: (1) Secure an Operational Technology (OT) Environment, an Industrial Control Systems (ICS) Environment, a Supervisory Control and Data Acquisition (SCAD A) Environment, and / or a Distributed Control System (DCS) environment on a Private Onion Routing Network; and (2) Direct Outbound Traffic Through the Private Onion Routing Network; (5) Use of a Virtual Device (Such as Implemented in a Cloud Server) to Secure Virtual Assets on a Private Onion Routing Network; (6) Hidden service(s) Management CLI Tool (likely both a CLI tool and a GUI); (7) Automated Build and Deployment of a Private Onion Routing Network with Customer Restricted Access of all Entry and Exit Nodes; (8) Management CLI Tool for Node Function Classification on a Private Onion Routing Network (likely including a CLI tool and a GUI); (9) Technical Framework and Infrastructure for Licensing a Private Onion Routing Network; and (10) Importing TLS Ciphers into Private Onion Routing Network Build via Configuration File.

[0022] 1 - Identity (or Authentication) Implementation on an Onion Routing Network & Identity (or Authentication) Management for Hidden service(s) Access on a Private Onion Routing Network

[0023] In examples of prior systems, there is no way to require identity for network access on an onion routing network and / or there is no identity management for hidden service(s) access. In examples of prior systems, hidden services may be given access control based onkeys, but the hidden systems do not have access control based on identity management. Even if hidden service(s) require identity, identity based access to hidden service(s) is not part of onion routing technology. In examples, identity management is implemented into onion routing network(s) and / or optional identity management requirements are granted for hidden service(s) access.

[0024] In examples, an identity flag is implemented which means that a layer of identity must be presented at that node in order for the traffic to be allowed. In examples on the network, there is a layer of encryption for each relay passed through and the identity flag is either (1) implemented on each layer of encryption; (2) required at the guard node; or (3) required at the directory authority level. In examples, the guard node is the first node on any given circuit of nodes. In examples, the directory authority level is implemented using directory authorities 104 are implemented as described herein. In examples, identity is required to access the root directory authority and identity is implemented at the directory level (such as by directory authorities 104 described below).

[0025] In examples, identity is implemented by: (1) adding an identity flag that requires identity on every node at every point of contact; (2) requiring identity on guard nodes, so the identity is only required at the beginning of each circuit; and / or (3) requiring identity directory authorities, so the identity is required to access the directory authorities. In examples, identity is required on both the guard node and the directory authority node. In examples, the guard node code includes an additional check against the packet it has decrypted for identity information (such as an identity token). In examples, a database is included for the guard node code to check against. In examples, the database may include (1) a distributed hash table similar to how hidden service(s) directories work; or (2) a designated identity relay (similar to directory authorities, but not public to the consensus) that the node would verify against.

[0026] In examples, the distributed hash table is segmented so that the description of an onion address is only accessible to identities that are attached to the onion address. In examples, an identity has a client authorization key specifically attached to it so that the client authorization can be granted or revoked from the identity. In examples, the client authorization key is added to all hidden services that an administrator granted the identity of the user access to. In examples, when an account is deleted or paused, the identity keys are revoked from the hidden services as they are attached to the identity of the account.

[0027] In examples, identity applies at two primary levels, the directory authority and the hidden service directory. In examples, before providing a consensus fde, the directory authority verifies identity information of a user, such as by verifying an appropriate identity token. In examples, this consensus file is what allows the client device to have the list of accessible relays that the network uses. In examples, the hidden service directory is where the cryptographic hostname is sent in order to receive details that will allow for the rendezvous with the hidden service. In examples, when a service (or other resource) is requested from either directory, the system first verifies that the appropriate identity token (such as a JSON Web Token (JWT)) is provided with the appropriate permissions to access the service (or other resource) and provides access to the service (or other resource) when the appropriate identity token is provided with the appropriate permissions and any other preexisting requirements are met.

[0028] In examples, requiring identity to access an onion routing network has not been done because requiring identity removes some of the anonymity inherent in onion routing, which is resistant to de-anonymization. In examples, requiring identity to access an onion routing network allows the onion routing network to be closed, contrary to typical onion routing networks that are intended to be open to anyone. In examples, it is desirable to close an onion routing network to only be accessible to explicitly approved users. In examples, requiring identity to access an onion routing network advantageously minimizes the ability for malicious actors to try to exploit the onion routing network so that only those who are explicitly provided access (such as customers) are allowed to access the network. Said another way, requiring identity for access to an onion routing network minimizes access to exploits by malicious actors by limiting access to the onion routing network to a set of identified users, but also reduces anonymity in the onion routing network.

[0029] 2 - Technical Framework and Infrastructure for Building a Private Onion Routing Network

[0030] In examples of prior systems, onion routing networks are publicly hosted, resulting in a variety of technical concerns, including: (1) bad actors being able to host malicious relays; (2) inconsistency in the size or availability of the network; and (3) lack of resources for technical support. In examples of prior systems, there is no central location for monitoring all the relays on the network. In examples, this can be solved at the system level by hosting the relays privately so that others cannot host malicious relays. In examples, the solution enables scaling of the relays as needed, so that the size and availability of thenetwork is controllable. In examples, there is also the ability to monitor every relay on the network, which helps with uptime, maintenance and technical support. In examples, the solution facilitates viewing what is happening on the entire network, which isn’t possible on a publicly hosted network. In examples, the solution allows system wide updates, which isn’t possible on a publicly hosted network.

[0031] In examples, at least one cloud computing service / web service (such as Amazon Web Services (AWS), Google Cloud Platform (GCP), Microsoft Azure, etc.) is used to create infrastructure (such as virtual server(s)) as code that is able to build machines that host the onion routing network. In examples, a program deploys and initially configures the machines. In examples, the network can expand (or contract) as needed using this configuration. In examples, system wide updates can be installed through the same process that allows deployment of the program onto the machines. In examples of prior systems implementing publicly hosted networks, there are issues with computers that are of the same “family” (such as on the same subnet being hosted at too large of scale). In examples of the private onion routing network, the network is configured to be able to work with nodes in the same “family”, which is counter to the publicly hosted network methodology. In examples of systems implementing a publicly hosted network, too many nodes of the same family may mean that there is an attack on the network, trying to take over a large percentage of the network to influence the consensus or view peoples traffic at the entry / exit node level. In examples implementing a privately hosted onion routing network, these issues and concerns are mitigated.

[0032] In examples of current publicly hosted onion routing network (such as the onion routing network created by the TorProject), the publicly hosted onion routing network may be used to provide anonymity in part through being publicly hosted. In examples, it is difficult to limit access to publicly available onion routing networks. In examples, privately hosted onion routing networks are used to limit access to the onion routing networks. In examples implementing a privately hosted onion routing network, the privately hosted onion routing network is used to secure assets from hacking attempts by: (1) mitigating the possibility of bad actors hosting malicious relays; (2) avoiding inconsistency of network size or availability by allowing scalability options; (3) avoiding lack of resources for technical support; and (4) implementing monitoring and software updates at a network level. In examples, privately hosted onion routing networks can be quickly created, expanded, retracted, and destroyed, which allows for more flexibility in scaling and support.

[0033] 3 - Automated and Configurable Build, Deployment, and Upkeep of a PrivateOnion Routing Network

[0034] In examples of prior systems, onion routing networks are run on various operating systems, with various configurations, deployed onto varying amounts of machines. In examples of prior systems network designs, varying versions of libraries are used which have to be built into deployed packages. In examples of prior systems, the customizability of the network design requires support at a technology level and that updates only occur when a network stakeholder approves, which requires access to (or copies of) historical libraries. In examples of prior systems, entire onion routing networks are not built and deployed privately and the publicly hosted nature of the technology makes a privately hosted onion routing network counter-intuitive.

[0035] In examples, methodologies were created to build all the various clients and configurations necessary and to deploy an entire network at the same time and scale the entire network as needed. In examples, automated and configurable builds can be implemented for specifical relays or an entire array of relays comprising an entire network. In examples, various aspects of the machines may include: machine size, the machine location, the machine name, the operating system, the packages loaded, the configuration of the relay (what type of relay it is and what it functions as), how it can be accessed, and so forth. In examples, a modularized build and deployment process allows building and deployment for different operating systems; library versioning selection; scripting of process(es) for creating various machines that the network will be hosted on; and scripting of process(es) for deploying the client software onto the various machines. In examples, the builds may be created using configuration files run by automation and scripting software (such as Crossplane, Chef, Terraform, Puppet, Ansible, Pulumi, CloudFormation, scripting, etc.) to automate: (1) the creation of the machines; (2) the tasks that are run on the created and configured machines; and (3) tasks to keep the network up and stable. In examples, secure access is maintained by having backups of the versions of the library used on that network. In examples, a build process is created that includes variables that allow you to dictate operating systems, package versions, etc.

[0036] While prior systems may have included (1) processes people can follow to setup a node / relay on the publicly hosted network and (2) installation scripts for client devices utilizing an onion routing network, there is no methodology for full build and deployment of an onion routing network. In examples, a privately hosted onion routing network offersimprovements for configuring and deploying an entire network as it (1) is designed for the task; (2) allows customization of every node of the network; (3) enable simultaneous deployment of nodes in the network; and is specific to package versioning and the chosen operating system for the network deployment. Prior public onion routing networks (such as Tor) require a number of people to be involved in changes relating to expanding, shrinking, or adjusting types of relays. In examples of public onion routing networks, it may be necessary to call people, present at conferences, and / or ask for volunteers to set up new parts of the network after showing the volunteers how to perform the actions and hoping they configure it correctly and that they are not bad actors. In private onion routing networks, these changes can be pushed out much more easily and quickly. In examples, the automated and configurable build, development, and upkeep of the private onion network allows for precision control over a large network because it provides the ability to: (1) adjust the network as needed; (2) quickly create new networks when something breaks or something new is needed; and (3) more easily test variations of onion routing networks to determine which options are best for specific use cases.

[0037] 4 - Use of a Hardware Device to; (1) Secure an Operational Technology (OT) Environment, an Industrial Control Systems (ICS) Environment, a Supervisory Control and Data Acquisition (SCAD A) Environment, and / or a Distributed Control System (DCS) environment on a Private Onion Routing Network; and (2) Direct Outbound Traffic Through the Private Onion Routing Network

[0038] In examples of prior systems, operational technology (OT) environments, industrial control system (ICS) environments, supervisory control and data acquisition (SCAD A) environments, and / or distributed control system (DCS) environments are difficult to secure, especially because they are often built with machines that (1) cannot easily be updated and (2) if updated, can cause serious problems to the OT environment, the ICS environment, the SCADA environment, and / or the DCS environment in which the machines are located, potentially causing harm to critical infrastructure sites. In examples of prior systems, it can be difficult to defend machines that cannot install security applications. In examples of prior systems, you cannot always update or install new software on machines, so you cannot always redirect traffic through the device that you need to redirect traffic through.

[0039] In examples, an external device is used to route traffic to and from the OT environment, the ICS environment, the SCADA environment, and / or the DCS environment. In examples, the external device is installed in front of other device(s) instead of software toperform the onion routing (in cases where the other device(s) cannot install the software or it is decided not to install the software on the other device(s)). In examples, the external device creates a connection for the other device(s) through the onion routing network. In examples, the external device has no open external inbound ports and only accepts external communication through the onion routing network, resulting in only people with hidden service(s) access, on the private onion routing network, being able to access the machines inside the OT environment, the ICS environment, the SCADA environment, and / or the DCS environment. In examples, the external device takes the output traffic and passes it through the private onion routing network. In examples, the external device obscures the open ports of the previously unsecured other device(s) from the wider external network, but those with client access through the onion routing network (such as through client software or another external device) can still access the external device(s) through the onion routing network. In examples, a supervisory control and data acquisition (SCADA) system could be one of the other device(s) and it could have an external device in front of it. In examples, the SCADA system could be pointed to by the external device for those with the client and permission to access the SCADA system through the external device so that the SCADA system can be accessed through the onion routing network through the external device for those with the client and permission, while remaining obscured from the wider external network.

[0040] In examples, the external device goes in front of the local network and is able to set hidden services to the machines that need external access. In examples, access controls can be set and hidden services can be turned on and off on the external device. In examples, the external devices includes firewall rules that block inbound traffic (in examples, this can be done using nftables or in other ways). In examples, hidden service(s) creation and access control is implemented via a configuration file and an auth file. In examples, firewall rules block outbound traffic except as directed through the onion routing network. In examples, an application / computer program running on a device takes traffic that is trying to go outbound and redirects it through the onion routing network. In examples, the application / computer program maps IP addresses from desired destinations to onion addresses (where onion addresses (also known as hidden services address or Yisda address) is an identifying string of characters (such as letters and numbers) such as an identifying address using the “.onion” suffix or an identifying address using the “.yisda” suffix) and routes to that onion address the proper port and proxy as necessary. For example, if outbound traffic received from example IP address 192.100.100.1 is destined for example IP address 200.100.100.1, theapplication / computer program will know to map the IP addresses to the onion address that is attached to 200.100.100.1 and then route it to that onion address through the proper port and proxy as necessary.

[0041] In examples of prior systems, commercial firewalls are used for security of OT environments, the ICS environments, the SCADA environments, and / or the DCS environments. While commercial firewalls are good for certain purposes, they have open ports, are easily misconfigured, and require substantial manual maintenance. In addition, firewalls are not inherently secure, but provide the possibility for security when implemented correctly. In examples of commercial firewalls, physical installation may provide just the illusion of security if not property setup and used. In examples, a private onion routing network implemented as described herein is inherently secure because it comes with ports off / blocked and security software installed, such that it is not possible to use the product without getting the security that is provided by using it.

[0042] In examples of prior systems, commercial routers are used to direct network traffic and are not capable of securing operational technology system in the same way as the external device described herein. In examples, commercial routers have a different purpose than private onion routing network(s) described herein because the redirection of traffic in the private onion routing network(s) described herein needs to be performed at a device that has the network executable on it and that can send the traffic through a proxy to a network created hostname. In examples, a router wouldn’t be able to accomplish this task unless it was able to host the client executable on it. In examples, using the external device described herein is difficult such that the device that remotely accesses the previously unsecured other device(s) through the onion routing network has to be configured in a way to be able to access the network through the wider external network without open inbound ports using various applications while still working as intended. In examples, the external device allows micro segmentation to devices that cannot easily implement remote access solutions, while still providing remote access without necessarily having to change anything in the environment of the previously unsecured other device(s) (such as Supervisory Control and Data Acquisition (SCADA) or Operation Technology (OT) system). In examples, use of the external device allows for additional security to be added to the previously unsecured other device(s) without having to change the previously unsecured other device(s) (such as a SCADA or OT system itself, even if there are noticeable changes in how the SCADA systemis accessed. In examples, this allows modem security to systems without changing the systems themselves (such as older systems thar are difficult to update or adjust).

[0043] 5 - Use of a Virtual Device (Such as Implemented in a Cloud Server) to Secure Virtual Assets on a Private Onion Routing Network

[0044] In examples of prior systems, not all virtual assets are able to download, install, or host onion routing network software and thusly cannot protect themselves with software. In examples of prior systems, some virtual assets that can install, host, or download the software are still unable to for reasons regarding permissions or cybersecurity compliance. In examples, a private onion routing network provides remote access to virtual device(s). In examples, an external virtual device (or virtual machine) is able to point at a secured virtual asset (such as a secured virtual device or secured virtual machine) that it can see to create remote access to it. In examples, the external virtual device can act as a direct barrio or it can work on the side. In examples, the external virtual device (or virtual machine) may act as a barrier for the secured virtual asset (such as the secured virtual device or secured virtual machine), where the external virtual device is the only machine that has access to the secured virtual asset (such as the secured virtual device or secured virtual machine). In examples, the external virtual device (or virtual machine) may provide an additional layer of access to the secured virtual asset (such as the secured virtual device or virtual machine). In examples, the external virtual device (or virtual machine) is a hidden service inside of a private virtual private cloud (“VPC”, which is a secure, isolated private cloud hosted within a public cloud) that allows access to a machine outside of the private VPC while still allowing other machines in the private VPC to access the hidden service.

[0045] In examples, an external virtual device is able to secure a virtual asset through a private onion routing network. In examples, using an external virtual device to secure a virtual asset through a private onion routing network has variations based on whether or not the cloud environment allows Dynamic Host Configuration Protocol (DHCP). In examples, a virtualized external device includes the client software and has a hidden service(s) pointed towards the secured virtual asset. In examples, the virtual asset secures firewall rules in various ways. In examples where the secured virtual asset can have its address assigned to it via DHCP on the external cloud device, the external cloud device functions like a machine being physically in front of another machine. In examples where the secured virtual asset cannot have its addressed assigned to it via DHCP on the external cloud device, inbound connections are shut down / blocked except for through the address of the external virtualdevice at the very specific port that the hidden service(s) is being pointed to such that no other devices can access the hidden service(s). Examples where the secured virtual asset can have its address assigned to it via DHCP on the external cloud device are more secure than examples where the secured virtual asset cannot have its address assigned to it via DHCP on the external cloud device.

[0046] In examples of prior systems, cloud security may primarily be provided by identity management and firewall rules. In examples implemented according to this disclosure, it is no longer necessary to be concerned about misconfiguring inbound firewall rules as they are all meant to be turned off. In examples, misconfiguration is a primary lead in what causes hacks in cloud environments. In examples, if you are able to use DHCP, it can help with cloaking device(s) address(es) behind a secure external device in addition to protecting the device(s) via permissioning. In examples, the external virtual device can be used to provide micro segmentation security in a cloud environment, which can simplify the security of the secured virtual asset and make the private onion hosting network adaptable to different environments.

[0047] 6 - Hidden service(s) Management CLI Tool (likely both a CLI tool and a GUI)

[0048] In examples of prior systems, hidden service(s) are managed manually. In examples managing hidden services manually, if there is an emergency and the hidden services need to be shut down, the hidden services may not be able to be shut down in time. In examples managing hidden services manually, if there is an issue with identity and access needs to be quickly removed for a specific user, the user may not be able to be removed in time. In examples of prior systems, if you want to be able to manage large hidden services with lots of users or rules, it is time consuming because of the manual implementation. In examples, hidden services can now be managed using human language using a command-line interface (CLI) format without in depth knowledge about hidden services. In examples, the CLI format entry allows the system to communicate through the internal network when it references external application programming interfaces (APIs), except for when the hidden service pulls in its identity token. In examples using the CLI format to manage hidden services, a user can add services in understandable language (such as “add service”) without knowing what file to change the configuration in, thereby users to manage hidden services more easily with less time. In examples, this allows for less time to be used in training users and in actually changing / altering hidden services.

[0049] In examples, a series of automations may allow: (1) addition of hidden service(s); (2) removal of hidden service(s); (3) addition of access for users; (4) removal of access for users; (5) changing hidden service(s); and (6) monitoring hidden service(s). In examples, these automations enable users to easily work with hidden services without having to worry about running into security risks that come from only being able to manually change configurations. In examples, Ansible playbooks are implemented that interact with secured assets that are hosting hidden services via SSH hidden service(s) using secure key secrets. In examples, the Ansible playbooks allow a verified user to submit changes, such as: (1) adding or removing users; (2) requesting monitoring logs; (3) changing hidden service(s); (4) adding hidden service(s); and (5) removing hidden service(s). In examples, this is accomplished by templatizing the management of these actions and then placing the templates for the management together. In examples, the specifics come to the names of folders, which you can save as variable in the portal. In examples, scripts (such as python or bash scripts) are used to automate actions. In examples, multiple automated actions are accessed at a time securely using secret managers. In examples, a template is included for each hidden service(s) enabling automation of a full networks worth of possibilities instead of just scripts specific to each secured asset.

[0050] 7 - Automated Build and Deployment of a Private Onion Routing Network with Customer Restricted Access of all Entry and Exit Nodes

[0051] In examples of prior systems, entry and exit nodes contain important traffic information that can allow someone who owns both the exit and entry nodes to read traffic. In examples of prior systems where malicious actors own the accompanying entry and exits nodes, the malicious actors could, with effort and a substantial control, read parts of users network traffic when they own the accompanying entry and exits nodes. In examples of prior systems, permissioning tools are used on identity management interfaces. In examples, a private onion networks are centrally created and managed (such as a by a service provider), while giving users control over edge relays. In examples, a private onion routing network is created through automated tools that allow creation and management of the complicated part of the private onion routing network by a service provider, while allowing users to retain full access and control of the entry and exit nodes. In examples, the service provider can configure an entire network that they do not have access to with relative ease. In examples, entry and exit nodes often have the most potential data on the traffic they are communicating, which would allow the users to hold more of their data if desirable (such as from a securityperspective) or necessary (such as from a regulatory perspective). In examples, the users have control over more of their data and of the machines that will be routing a lot of their traffic, while not requiring the full complication of managing the private onion routing network.

[0052] In examples, control of the entry and exits nodes is given to the client on an automated basis. In examples, since consensus votes for relays of certain types, the primary concern is that it can only work for people that are licensing their own network. In examples, it requires that (1) the client be comfortable hosting the directory authorities as well if the nodes of the client are voted as a guard node; or (2) that the directory authorities be banned from being a guard node. In examples, a script is generated that scans consensus files and if the script identifies that a particular node has been assigned as an exit / entry node, the script will make it so that the hidden service(s) client authorization allows the customer’s key in, and the customer’s key only. In examples, a reverse script is used when a particular node is voted off as an entry / exit node, then the hidden service(s) client authorization is given back to the company based administrator for the whole network.

[0053] 8 - Management CLI Tool for Node Function Classification on a Private Onion Routing Network (likely including a CLI tool and a GUI)

[0054] In current systems, there is not an easy way to manage node classification of a relay on an onion routing network other than manually changing configurations. In examples, it is desirable to change what role a relay plays in a private onion routing network using simpler interfaces, such as a command-line interface (CLI) or graphical user interface (GUI). In example systems, a consensus is voted on periodically (such as every hour) and the consensus decides trusts and assigns flags according to network statistics and the configuration files of the relays in question. In examples, strict voting rules for what a relay looks like are not required and instead the flags are accepted that are suggested by the consensus as long as a relay can be validates as an authenticated relay. In examples, the consensus accepts the flags of the relay as its permission to be a certain role, instead of deciding to possibly allow it to be a certain role if it fits certain criteria. In examples, this allows for more control over the network and can reduce the time to get a relay working as a certain role and it also allows relays to be guaranteed the roles are as designed. In example systems, relays cannot be assigned to certain functions and you can just configure them to try to take a function and might get assigned it after a period of time. In examples, the client doesn’t have control over the network, but only has control over the configurations of the network. In examples, whilethe network configurations can be changed, there is no management interface that allows the client to see what it is voted as, where it is at, what its configuration is, and gives you options to change it.

[0055] In examples, a central authority decides the consensus based on administrative input and not on voting or trust. In examples, scripts with a frontend interface for function classification management are used. In examples, a consensus is created that is not voted on, but is selected by a central authority such that no relays can be added unless approved. In examples, this is performed by taking away the hourly voting process, and instead having it check the central authority to see if anything has change. In examples, it would still include consensus files that expire, and changes of keys. In examples, there is still security so someone cannot attempt to use an old (such as fifty day old) consensus file.

[0056] In examples, Ansible playbooks are created which are able to check configuration files, update them, and remove things from them. In examples, a script is used to check the consensus file. In examples, you can see what the current configurations are, what flags it intends to get, what flags it actually has, and have a GUI which interfaces with the Ansible Playbooks scripts which allow you to either remove certain configurations or add certain configurations.

[0057] In current examples, there is a current form of consensus on the publicly hosted onion routing network, however this serves a useful purpose for publicly hosted networks while only causing issues for privately hosted networks. In examples, there is no current management of function classification in this form.

[0058] 9 - Technical Framework and Infrastructure for Licensing a Private Onion Routing Network

[0059] In current examples of publicly available onion routing networks, it is difficult to create, deploy, maintain, and / or monitor onion routing network(s). In current examples, it is difficult to make the builds as desired, difficult to deploy the builds to the spots desired, difficult to create network wide monitoring, and / or there are many small things that can break the network that can be difficult to maintain and / or script. In examples, a technical framework is used for creating a private onion routing network within a license agreement (which might take various shapes). In examples, this allows for hosting of private onion routing networks, allowing users to have a network created and usable and private owned and hosted without having to understand the technical aspects to make it work and get it setup. Inprior systems, anonymous networks require public hosting. In contrast, the private onion routing networks are being used for non-anonymous purposes and are amenable to private hosting. In examples, the technology can be licensed for creating, deploying, maintaining, and / or monitoring the network. In examples, various aspects can be licensed, including: (1) the automated and configurable build process; (2) the Terraform scripts that deploy the build processes to the cloud; (3) the monitoring system; and / or (4) the automations for things like key replacement, hidden service(s) management, and / or identity management.

[0060] 10 - Importing TLS Ciphers into Private Onion Routing Network Build via Configuration File

[0061] In current examples, there is no way to change the ciphers (such as TLS ciphers) in onion routing source code without changing hardcoded variables because ciphers are typically implemented directly into the source code. In examples, ciphers can be implemented into a private onion routing network using a list of ciphers can be uploaded in a file and then the code would read the list and then upload the ciphers into the build and use those ciphers in the private onion routing network. In examples, this would make it easy to change out ciphers (such as when new ciphers are created with additional security) to stay up to date with security. In examples, in order to receive a configuration file that allows import of ciphers, the private onion routing network needs to be programmed in a more open way where it is able to use any cipher that it receives, rather than hardcoded variable. In examples, a way is introduced to insert ciphers into the source code via a text file that is read during the build process. In examples, during the build process there is a variable that links the build to the file, which then lists the names of the ciphers that are to be built. In examples, the names of the ciphers that are to be built are then used inside the build process to pick those ciphers, assuming they are available in the packages being built, and then builds them into the executable.

[0062] Figures 1 A-1C are block diagrams illustrating example systems 100A-100C for reaching consensus between directory authorities in a privately hosted / private onion routing network 102. Figure 1 A shows example system 100A which includes a plurality of directory authorities 104 (such as directory authority node 104-1, directory authority node 104-2, and any quantity of optional directory authorities 104 through optional directory authority node 104-A). In examples, the directory authorities 104 are communicatively coupled using at least one network 106. In examples, the set of directory authorities 104 may include any quantity of directory authorities greater than one, such as between 2-20 directory authorities,though other quantities can be used in other implementations. In examples, the directory authorities 104 periodically communicate with each other and vote on a consensus and publish a consensus file. In examples, the periodicity of the communication and consensus between the directory authorities 104 may be a certain quantity of second, minutes, hours, days, etc. In examples, the consensus file includes data that details relevant information about each of the relays on the network. In examples, the consensus file includes information such as the address and the assigned flags for the voted upon relays.

[0063] Figure IB shows an example system 100B similar to system 100A where the directory authorities 104 are root directory authorities (RD A) (such as root directory authority node 104-1, root directory authority node 104-2, and any quantity of optional root directory authorities 104 through optional root directory authority node 104- A). In examples, a root directory authority node 104 is a directory authority that periodically votes on and publishes the consensus file. Figure 1C shows an example system 100C similar to system 100B where the directory authorities 104 are root directory authorities (RD A) (such as root directory authority node 104-1, root directory authority node 104-2, and any quantity of optional root directory authorities 104 through optional root directory authority node 104-A) and also including at least one fallback directory authority (FDA) 108 (such as fallback directory authority node 108-1 and any quantity of optional fallback directory authorities 108 through fallback directory authority node 108-B). In examples, when a root directory authority node 104 fails (such as root directory authority node 104-1), a fallback directory authority node 108 (such as fallback directory authority node 108-1) replaces the failed root directory authority node 104 so there are still a certain quantity of functioning directory authorities 104 at all times.

[0064] Figure 2 is a block diagram illustrating example system 200 for communication with a hidden service in a privately hosted / private onion routing network 102. In examples, system 200 includes a privately hosted / private onion routing network 202 (which could be implemented by privately hosted / private onion routing network 102) having a plurality of networking nodes communicatively coupled in at least one network. In examples, privately hosted / private means that the plurality of network nodes are controlled by a single entity. In examples, the plurality of network nodes in the privately hosted / private onion routing network 202 includes: a plurality of relay nodes 204 (such as any quantity of relay nodes 204- 1, 204-2, 204-3, etc.); (2) at least one introduction point node 206 (such as any of optional introduction point node 206-1, optional introduction point node 206-2, optional introductionpoint node 206-3, etc.); (3) at least one hidden service(s) directory node 208; and at least one hidden service(s) node 210. In examples, privately hosted / private onion routing network 202 enables cloaking of hidden device(s) / network(s) 212. In examples, hidden device(s) / network(s) 212 include a vault and / or any number of device that are hidden from external discovery and access by the at least one hidden service(s) node 210.

[0065] In examples, the privately hosted / private onion routing network 202 allows connection from client computing device(s) 214 external to the privately hosted / private onion routing network 202. In examples, the client computing device(s) 214 are configured to communicate identity information (such as an identity token) and an onion address for a hidden service to a directory authority node(s) 216 across at least one network. In examples, directory authority node(s) 216 is configured to verify that the identity information (such as an identity token) received from the client computing device is associated with permissions to access the consensus file from the directory authority node(s) 216. In examples, the client computing device(s) 214 is configured to download a most recent consensus file from a directory authority node(s) 216 in the privately hosted / private onion routing network 202. In examples, directory authority node(s) 216 is implemented by a directory authority node 104, root directory authority node 104, and / or fallback directory authority node 108 of private onion routing network 102 described above where directory authority node(s) 104, root directory authority node(s) 104, and / or fallback directory authority node(s) 108 receives a published consensus file as described with references to systems 100A-100C above).

[0066] In examples, the client computing device(s) 214 are configured to communicate identity information (such as an identity token) and an onion address for a hidden service to the hidden service(s) directory node(s) 208 across at least one network and optionally through optional relay node 204-13 and optional relay node 204-14 (or any combination of optional relay nodes 204). In examples, the hidden service(s) directory node(s) 208 are configured to verify that the identity information (such as an identity token) received from the client computing device is associated with permissions to access the hidden service identified by the onion address. In examples, the client computing device(s) 214 is configured to communicate with the hidden service(s) directory node(s) 208 to verify the existence of the hidden service(s) node(s) 210. In examples, the client computing device(s) 214 is configured to receive a descriptor for the hidden service(s) node(s) 210 from the hidden service(s) directory node(s) 208. In examples, the client computing device(s) 214 is configured to generate meeting rendezvous details using a one-time password and a rendezvous address fora rendezvous point node 218. In examples, the rendezvous point node 218 is a relay connecting a client to an onion service, where each party builds a three-hop (or other quantity of hops) circuit, meeting at the rendezvous point.

[0067] In examples, the client computing device(s) 214 are configured to communicate identity information (such as an identity token) to other nodes it communicates with in the privately hosted onion routing network 202 (such as any of relay nodes 204, introduction point nodes 206, rendezvous point node 218, etc.) for verification of permission before the nodes will communicate with the client computing device(s) 214. In examples, a guard node (which is the first relay node 204 the client computing device(s) 214 communicates with when communicating with the privately hosted onion routing network 202) require the identity information (such as an identity token) to be received and permission verified to access the privately hosted onion routing network 202 before the guard node allows the client computing device(s) 214 any access to the privately hosted onion routing network 202.

[0068] In examples, the client computing device(s) 214 is configured to communicate meeting details to at least one of the introduction point(s) nodes 206 (such as optional introduction point node 206-1) through optional relay node 204-10, optional relay node 204- 11, and optional relay node 204-12 (and any combination of optional relay nodes 204)) received in the descriptor to establish a rendezvous point at the rendezvous point node 218 to meet with (establish a connection with) the hidden service(s) node(s) 214.

[0069] In examples, the hidden service(s) node(s) 210 are configured to receive meeting details from the introduction point(s) nodes 206 (such as introduction point node 206-1) through optional relay node 204-1 and optional relay node 204-2 (and any combination of optional relay node 204)). In examples, the hidden service(s) node(s) 210 are configured to approve meeting details. In examples, the hidden service(s) node(s) 210 are configured to connect to the rendezvous point node 218 to meet with (establish a connection with) the client computing device(s) 214. In examples, the hidden service(s) node(s) 210 are configured to provide the one-time password for verification by the client computing device(s) 214.

[0070] In examples, the client computing device(s) 214 is configured to receive a one-time password from the hidden service(s) node(s) 210 through the rendezvous point node 218 (such as from hidden service(s) node(s) 210 through optional relay node 204-17, optional relay node 204-16, and optional relay node 204-14 (and any combination of optional relaynodes 204) to rendezvous point node 218 and then from rendezvous point node 218 through optional relay node 204-16 and optional relay node 204-15 (and any combination of optional relay nodes 204) to client computing device(s) 214 (or any quantity of optional relay nodes 204 on either side of the rendezvous point node 218). In examples, the client computing device(s) 214 is configured to verify the one-time password matches the expected one-time password. In examples, assuming all else is done correctly, the connection between the client computing device(s) 214 and the hidden service(s) node(s) 210 (and by extension, the hidden device(s) / network(s) 212) is established.

[0071] Figure 3 is a block diagram illustrating example circuit 300 for circuit encryption within a privately hosted onion routing network 302. In examples, circuit 300 includes client computing device(s) 304, relay nodes 306 (including any quantity of relay nodes 306, such as relay node 306-1, relay node 306-2, relay node 306-3, etc.) within the privately hosted onion routing network 302, and an external device 308. In examples, when client computing device(s) 304 reach out through the privately hosted onion routing network 302 (such as to a website or other network resource), data 310 will be encrypted N number of times, where N represents how many relay nodes 306 the data is going through between client computing device(s) 304 and the external device 308. For example, N=1 in the exemplary embodiment shown in Figure 3 with three relay nodes 306 (relay node 306-1, 306-2, and 306-3). In other examples, greater or fewer quantities of relays are used, resulting in greater or fewer quantities of encryption. In examples, the key for each relay node 306 stage is encrypted via AES and agreed upon with the relevant relay node 306 via the Diffie-Hellman Key Exchange so that each relay node 306 can decrypt the data 310 at its stage of the process. In examples, the data 310 travels through the circuit 300 from the client computing device(s) 304 toward the external device 308 and the various layers of encryption are decrypted at each relay node 306 until the decrypted data is provided to the external device 308. In examples, the data 310 travels through the circuit from the external device 308 toward the client computing device(s) 304 and the various layers of encryption are added at each relay node 306 until the encrypted data is provided to the client computing device(s) 304 fully encrypted. In examples, the client computing device(s) 304 has the keys needed to decrypt the fully encrypted data 310 and to decrypts and process the data 310.

[0072] Figure 4 is an example method 400 for creating hidden service(s). In examples, method 400 begins at block 402 with downloading a network executable. In examples, method 400 proceeds with block 404 with adding hidden service(s) configuration pointing toInternet Protocol (IP) address and port of hidden service(s) being protected. In examples, method 400 proceeds with block 406 with creating hidden service(s) 406. In examples, method 400 proceeds with block 408 with identifying introduction points to be used by clients to access hidden service(s). In examples, method 400 proceeds with block 410 with packaging relevant information regarding introduction points and creating descriptor 410. In examples, method 400 proceeds with block 412 with publishing a descriptor to the hidden service(s) directory.

[0073] Figure 5 is an example method 500 for providing a consensus file to a client computing device (such as a client computing device(s) 214). In examples, method 500 is performed to obtain the consensus file with an onion address used in method 600 described below. In examples, method 500 is combined with method 600 in various ways. In examples, method 500 begins with block 502 with receiving identity information from a client computing device (such as client computing device(s) 214) at a directory authority node(s) (such as directory authority node(s) 216). In examples, method 500 proceeds with block 504 with verifying that the identity information received from the client computing device (such as client computing device(s) 214) is associated with permissions to access the consensus file. In examples, this verification occurs at the directory authority node(s) (such as directory authority node(s) 216). In examples, method 500 proceeds with block 506 with communicating a consensus file (such as a most recent consensus file) from the directory authority node(s) (such as directory authority node(s) 216) to the client computing device (such as client computing device(s) 214). In examples, the most recent consensus is downloaded from the directory authority node(s) (such as directory authority node(s) 216).

[0074] Figure 6 is an example method 600 for accessing hidden service(s) (such as from hidden service(s) node(s) 210) from a client computing device (such as client computing device(s) 214). In examples, method 600 proceeds with optional block 602 with receiving an onion address at a client computing device (such as client computing device(s) 214). In examples, the onion address is extracted and selected from the consensus file received at the client computing device (such as client computing device(s) 214) using method 500. In examples, the onion address is selected by the user from options extracted from the consensus file or otherwise provided by a user. In examples, method 600 proceeds with block 604 with communicating identity information (such as an identity token) and the onion address from the client computing device (such as client computing device(s) 214) to a hidden service(s) directory node (such as hidden service(s) directory node(s) 208). In examples, method 600proceeds with block 606 with verifying that identity information (such as the identity token) received from the client computing device (such as client computing device(s) 214) is associated with permissions to access the hidden service (such as from the hidden service(s) node(s) 210) identified by the onion address. In examples, method 600 includes communicating with a hidden service(s) directory node (such as hidden service(s) directory node(s) 208) using a client computing device (such as client computing device(s) 214) to verify the existence of a hidden service(s). In examples, method 600 proceeds with block 608 with receiving a descriptor for a hidden service(s) from a hidden service(s) directory node (such as hidden service(s) directory node(s) 208) at a client computing device (such as client computing device(s) 214). In examples, method 600 proceeds with optional block 610 with generating meeting rendezvous details at a client computing device (such as client computing device(s) 214) using a one-time password and rendezvous address. In examples, method 600 proceeds with optional block 612 with communicating meeting details from a client computing device (such as client computing device(s) 214) to introduction point(s) received in a descriptor to establish a rendezvous point node (such as rendezvous point node 218) to meet with the hidden service(s). In examples, method 600 proceeds with optional block 614 with receiving one-time password at client computing device from hidden service(s) at rendezvous point node (such as rendezvous point node 218).

[0075] Figure 7 is an example method 700 for allowing access to hidden service(s) by client computing device. In examples, method 700 begins at block 702 with receiving meeting details at a hidden service(s) from an introduction point. In examples, method 700 proceeds with block 604 with approving meeting details at a hidden service(s). In examples, method 700 proceeds with block 606 with connecting the hidden service(s) to the client computing device at the rendezvous point. In examples, method 700 proceeds with block 608 with providing the one-time password for verification by the client computing device.

[0076] Figure 8 is an example method 800 for permissioning access to a private onion routing network (such as privately hosted / private onion routing network 202) by a client computing device (such as client computing device(s) 214). In examples, method 800 begins with block 802 with communicating identity information from a client computing device (such as client computing device(s) 214) to a node in the private onion routing network (such as privately hosted / private onion routing network 202). In examples, method 800 proceeds with block 804 with verifying that the identity information received from the client computing device (such as client computing device(s) 214) is associated with permissions toaccess the private onion routing network (such as privately hosted / private onion routing network 202). In examples, this verification occurs at any type of node (such as a relay node 204, a introduction point node 206, a hidden service(s) directory node(s) 208, a rendezvous point node 218). In examples, method 800 proceeds with block 806 with allowing communication from the client computing device (such as client computing device(s) 214) within the private onion routing network (such as privately hosted / private onion routing network 202).

[0077] The techniques introduced here can be embodied as special-purpose hardware (such as circuitry), as programmable circuitry appropriately programmed with software and / or firmware, or as a combination of special-purpose and programmable circuitry. Hence, embodiments may include a machine-readable medium having stored thereon instructions that may be used to program a computer (or other electronic devices) to perform a process. The machine-readable medium may include, for example, floppy diskettes, optical disks, compact disc read-only memories (CD-ROMs), magneto-optical disks, read-only memories (ROMs), random access memories (RAMs), erasable programmable read-only memories (EPROMs), electrically erasable programmable read-only memories (EEPROMs), magnetic or optical cards, flash memory, or other type of media / machine-readable medium suitable for storing electronic instructions.Computer System Overview

[0078] Embodiments of the present disclosure include various steps and operations, which have been described above. A variety of these steps and operations may be performed by hardware components or may be embodied in machine-executable instructions, which may be used to cause a general -purpose or special-purpose processor programmed with the instructions to perform the steps. Alternatively, the steps may be performed by a combination of hardware, software, and / or firmware. As such, Figure 9 is an example of a computer system 900 with which embodiments of the present disclosure may be utilized. For example, the computer system 900 may implement directory authority(s) 104, root directory authority(s) 104, fallback directory authority(s) 108, relay node(s) 204, introduction point node(s) 206, hidden service(s) directory node(s) 208, hidden service(s) node(s) 210, hidden device(s) / network(s) 212, client computing device(s) 214, directory authority node(s) 216, rendezvous point node(s) 218, client computing device(s) 304, relay node(s) 306, external device(s) 308, and any other components of system 100A, system 100B, system 100C, privately hosted / private onion routing network 102, system 200, privately hosted / privateonion routing network 202, system 300, and / or privately hosted onion routing network 302 described herein. According to the present example, the computer system 900 includes processor(s) 902, memory(s) 904, optional network interface(s) 906, optional display device 908, optional input device 910, and optional power source 912.

[0079] In exemplary embodiments, the processor(s) 902 can be any known processor, such as a general purpose processor (GPP) or special purpose (such as a field-programmable gate array (FPGA), application-specific integrated circuit (ASIC) or other integrated circuit or circuitry), or any programmable logic device. In exemplary embodiments, the at least one memory 904 can be any device, mechanism, or populated data structure used for storing information. In exemplary embodiments, the at least one memory 904 can be or include any type of volatile memory, nonvolatile memory, and / or dynamic memory. For example, the at least one memory 904 can be random access memory, memory storage devices, optical memory devices, magnetic media, floppy disks, magnetic tapes, hard drives, erasable programmable read-only memories (EPROMs), electrically erasable programmable read-only memories (EEPROMs), optical media (such as compact discs, DVDs, Blu-ray Discs) and / or the like. In accordance with some embodiments, the at least one memory 904 may include one or more disk drives, flash drives, one or more databases, one or more tables, one or more files, local cache memories, processor cache memories, relational databases, flat databases, and / or the like. In addition, those of ordinary skill in the art will appreciate many additional devices and techniques for storing information which can be used as the at least one memory 904. The at least one memory 904 may be used to store instructions for running one or more applications or modules on the at least one processor 904.

[0080] In exemplary embodiments, the optional network interface(s) 906 includes a cabled network interface configured for connection with a cabled media (such as but not limited to an Ethernet cable, a fiber optic cable, twisted pair, Category cabling, or other conductive or optical media). In exemplary embodiments, the optional network interface(s) 906 includes a wireless network interface and includes or is coupled to at least one optional antenna for communication with a network. In exemplary embodiments, the optional network interface(s) 906 includes at least one of an Ethernet interface, a cellular radio access technology (RAT) radio, a Wi-Fi radio, a Bluetooth radio, and a near field communication (NFC) radio. In exemplary embodiments, the optional network interface(s) 906 includes a cellular radio access technology radio configured to establish a cellular data connection (mobile internet) of sufficient speeds with a remote server using a local area network (LAN)or a wide area network (WAN). In exemplary embodiments, the cellular radio access technology includes at least one of Personal Communication Services (PCS), Specialized Mobile Radio (SMR) services, Enhanced Special Mobile Radio (ESMR) services, Advanced Wireless Services (AWS), Code Division Multiple Access (CDMA), Global System for Mobile Communications (GSM) services, Wideband Code Division Multiple Access (W- CDMA), Universal Mobile Telecommunications System (UMTS), Worldwide Interoperability for Microwave Access (WiMAX), 3rd Generation Partnership Projects (3 GPP) Long Term Evolution (LTE), High Speed Packet Access (HSPA), third generation (3G) fourth generation (4G), fifth generation (5G), etc. or other appropriate communication services or a combination thereof. In exemplary embodiments, the optional network interface(s) 906 includes a Wi-Fi (IEEE 802.11) radio configured to communicate with a wireless local area network that communicates with the remote server, rather than a wide area network. In exemplary embodiments, the optional network interface(s) 906 includes a near field radio communication device that is limited to close proximity communication, such as a passive near field communication (NFC) tag, an active near field communication (NFC) tag, a passive radio frequency identification (RFID) tag, an active radio frequency identification (RFID) tag, a proximity card, or other personal area network device.

[0081] In exemplary embodiments, the optional display device 908 includes at least one of a light emitting diode (LED), a liquid crystal display (LCD), a light emitting diode (LED) display, an organic light emitting diode (OLED) display, an e-ink display, a field emission display (FED), a surface-conduction electron-emitter display (SED), and a plasma display. In exemplary embodiments, the optional input device 910 include at least one of a touchscreen (including capacitive and resistive touchscreens), a touchpad, a capacitive button, a mechanical button, a switch, a dial, a keyboard, a mouse, a camera, a biometric sensor / scanner, etc. In exemplary embodiments, the optional display device 908 and the optional input device 910 are combined into a human machine interface (HMI) for user interaction with the computing device 900. In exemplary embodiments, optional power source(s) 912 is used to provide power to the various components of the computer system 900.

[0082] The components described above are meant to exemplify some types of possibilities. In no way should the aforementioned examples limit the disclosure, as they are only exemplary embodiments. The embodiments, structure, and methods described herein, including those below and above, can be combined together in various ways.Terminology

[0083] Brief definitions of terms, abbreviations, and phrases used throughout this application are given below.

[0084] The phrase “based on” does not mean “based only on,” unless expressly specified otherwise, in other words, the phrase “based on” describes both “based only on” and “based at least on”. Additionally, the term “and / or” means “and” or “or”. For example, “A and / or B” can mean “A”, “B”, or “A and B”. Additionally, “A, B, and / or C” can mean “A alone,” “B alone,” “C alone,” “A and B,” “A and C,” “B and C” or “A, B, and C.”

[0085] The phrases “in exemplary embodiments”, “in example embodiments”, “in some embodiments”, “according to some embodiments”, “in the embodiments shown”, “in other embodiments”, “embodiments”, “in examples”, “examples”, “in some examples”, “some examples” and the like generally mean the particular feature, structure, or characteristic following the phrase is included in at least one embodiment of the present disclosure and may be included in more than one embodiment of the present disclosure, in addition, such phrases do not necessarily refer to the same embodiments or different embodiments.

[0086] If the specification states a component or feature “may,” “can,” “could,” or “might” be included or have a characteristic, that particular component or feature is not required to be included or have the characteristic.

[0087] The term “responsive” includes completely or partially responsive.

[0088] The term “module” refers broadly to a software, hardware, or firmware (or any combination thereof) component. Modules are typically functional components that can generate useful data or other output using specified input(s). A module may or may not be self-contained. An application program (also called an “application”) may include one or more modules, or a module can include one or more application programs.

[0089] Keys, including cryptographic keys, can be used to sign, verify a signature, encrypt and / or decrypt digital data. Keys can include (but are not limited to) private keys, public keys, and other cryptographic keys as well as passwords and secrets. In examples, a key may be embodied as a string of characters.

[0090] In some configurations described herein, one or more symmetric encryption keys may be used. A symmetric encryption key (or simply “symmetric key”) may be used to encrypt and / or decrypt data. This is referred to as “symmetric” encryption / decry ptionbecause the same key can be used to encrypt and decrypt. Without limitation, symmetric keys may operate according to any of the following encryption: Twofish, Serpent, Advanced Encryption Standard (AES), Blowfish, CAST5, Kuznyechik, RC4, Data Encryption Standard (DES), Triple DES (3 DES), Skipjack, Safer+ / ++ (Bluetooth), IDEA and / or other cypher block coding (CBC) variations. Accordingly, even though AES keys are used in some examples below, any other symmetric keys could alternatively be used.

[0091] In some configurations described herein, asymmetric encryption may be used. A “public / private keypair,” which includes a private key and a corresponding public key, may be used in asymmetric encryption. The private key and public key may alternatively be referred to as an decrypting private key and an encrypting public key. The public key can be used to encrypt data, which can only be decrypted using the private key corresponding to the public key that was used for encryption. As used herein, the term “private key” may refer to a symmetric key or an asymmetric key.

[0092] This may be referred to as “asymmetric” encryption / decry ption because the same key is not used to encrypt and decrypt (or sign transactions). It is generally desirable to keep a private key (and sometimes the public key) secure. However, there is often a tradeoff between keeping keys secure and accessible when needed. Without limitation, asymmetric keys may operate according to any of the following encryption: Rivest-Shamir-Adleman (RSA) and Elliptic Curve Cryptography (ECC) (e.g., Curve25519), Edwards-curve Digital Signature Algorithm (EdDSA) (e.g., Ed25519), etc.

[0093] As used herein, the term “encrypting” or its variants, refers to converting data into a code to prevent unauthorized access. Encryption can be implemented in various ways, such as with symmetric encryption using a single encryption key to both encrypt and decrypt data or with asymmetric encryption using a public key to encrypt data and a corresponding private key to decrypt data.

[0094] Also, for the sake of illustration, various embodiments of the present disclosure have herein been described in the context of computer programs, physical components, and logical interactions within modern computer networks. Importantly, while these embodiments describe various embodiments of the present disclosure in relation to modern computer networks and programs, the method and apparatus described herein are equally applicable to other systems, devices, and networks as one skilled in the art will appreciate. As such, the illustrated applications of the embodiments of the present disclosure are notmeant to be limiting, but instead are examples. Other systems, devices, and networks to which embodiments of the present disclosure are applicable include, for example, other types of communication and computer devices and systems. More specifically, embodiments are applicable to communication systems, services, and devices such as cell phone networks and compatible devices. In addition, embodiments are applicable to all levels of computing from the personal computer to large network mainframes and servers.

[0095] While detailed descriptions of one or more embodiments of the disclosure have been given above, various alternatives, modifications, and equivalents will be apparent to those skilled in the art without varying from the spirit of the disclosure. For example, while the embodiments described above refer to particular features, the scope of this disclosure also includes embodiments having different combinations of features and embodiments that do not include all of the described features. Accordingly, the scope of the present disclosure is intended to embrace all such alternatives, modifications, and variations as fall within the scope of the claims, together with all equivalents thereof. Therefore, the above description should not be taken as limiting.Examples

[0096] Example 1 includes a private onion routing network comprising: a plurality of network nodes communicatively coupled by at least one network, the plurality of network nodes comprising: a plurality of relay nodes; at least one hidden services directory node; at least one hidden service node; at least one rendezvous point node; wherein the at least one hidden services directory node is configured to: receive identity information and an onion address for a hidden service from a client computing device across the at least one network; verify that the identity information received from the client computing device is associated with permissions to access the hidden service identified by the onion address; and communicate a descriptor for the hidden service to the client computing device across the at least one network, wherein the descriptor includes a rendezvous address for a rendezvous point node of the at least one rendezvous point node, wherein the rendezvous point node is where the client computing device meets with the at least one hidden service node.

[0097] Example 2 includes the private onion routing network of Example 1, further comprising: wherein the plurality of network nodes further comprises: at least one introduction point node configured to: receive meeting rendezvous details from the client computing device, wherein the meeting rendezvous details include a one-time password andthe rendezvous address for the rendezvous point node of the at least one rendezvous point node.

[0098] Example 3 includes the private onion routing network of Example 2, wherein: the at least one hidden service node is configured to: receive the meeting rendezvous details from the at least one introduction point node; approve the meeting rendezvous details; connect the at least one hidden service node to the rendezvous point node of the plurality of network nodes; provide the one-time password to the client computing device through the rendezvous point node for verification by the client computing device; and establish a connection with the client computing device through the rendezvous point node.

[0099] Example 4 includes the private onion routing network of any of Examples 2-3, wherein: the at least one hidden services directory node is configured to: publish the descriptor of the at least one introduction point node based on relevant information regarding the at least one introduction point node.

[0100] Example 5 includes the private onion routing network of any of Examples 1-4, wherein the identity information comprises an identity token.

[0101] Example 6 includes the private onion routing network of Example 5, wherein the identity token identifies a user of the client computing device.

[0102] Example 7 includes the private onion routing network of any of Examples 1-6, wherein the plurality of network nodes are initially deployed, configured, updated, and reconfigured using automated software.

[0103] Example 8 includes a system comprising: a computing device configured to: receive an onion address for a hidden service from a user; communicate identity information and the onion address for the hidden service to a hidden service directory node across at least one network to verify existence of a hidden service node associated with the hidden service; receive a descriptor for the hidden service from the hidden service directory node across the at least one network, wherein the descriptor includes a rendezvous address for a rendezvous point node where the computing device meets with the hidden service node; generate meeting rendezvous details using a one-time password and the rendezvous address of the rendezvous point node; communicate the meeting rendezvous details to at least one introduction point node received in the descriptor to establish the rendezvous point node to meet with the hidden service node; and receive the one-time password at the computing device from the hidden service node at the rendezvous point node.

[0104] Example 9 includes the system of Example 8, further comprising: circuitry configured to implement the hidden service node, the circuitry configured to: receive the meeting rendezvous details from the at least one introduction point node at the hidden service node; approve the meeting rendezvous details at the hidden service node; connect the hidden service node to the rendezvous point node; and provide the one-time password for verification by the computing device.

[0105] Example 10 includes the system of any of Examples 8-9, wherein the computing device is further configured to: download a most recent consensus at the computing device.

[0106] Example 11 includes a method for operating a private onion routing network, the method comprising: receiving, by a hidden services directory node of the private onion routing network, identity information and an onion address for a hidden service from a client computing device across at least one network; verifying, by the hidden services directory node, that the identity information received from the client computing device is associated with permissions to access the hidden service identified by the onion address; communicating, by the hidden services directory node, a descriptor for the hidden service to the client computing device across the at least one network, wherein the descriptor includes a rendezvous address for a rendezvous point node, wherein the rendezvous point node is where the client computing device meets with at least one hidden service node of the private onion routing network.

[0107] Example 12 includes the method of Example 11, further comprising: generating, at the client computing device, meeting rendezvous details using a one-time password and the rendezvous address for the rendezvous point node.

[0108] Example 13 includes the method of any of Examples 11-12, further comprising: receiving, by at least one introduction point node of the private onion routing network, meeting rendezvous details from the client computing device, wherein the meeting rendezvous details include a one-time password and the rendezvous address for the rendezvous point node.

[0109] Example 14 includes the method of Example 13, further comprising: receiving, by the at least one hidden service node, the meeting rendezvous details from the at least one introduction point node; approving, by the at least one hidden service node, the meeting rendezvous details; connecting the at least one hidden service node to the rendezvous point node; providing, by the at least one hidden service node, the one-time password to the clientcomputing device through the rendezvous point node for verification by the client computing device; and establishing, by the at least one hidden service node, a connection with the client computing device through the rendezvous point node.

[0110] Example 15 includes the method of any of Examples 13-14, further comprising: publishing, by the hidden services directory node, the descriptor of the at least one introduction point node based on relevant information regarding the at least one introduction point node.

[0111] Example 16 includes the method of any of Examples 11-15, wherein the identity information comprises an identity token.

[0112] Example 17 includes the method of Example 16, wherein the identity token identifies a user of the client computing device.

[0113] Example 18 includes the method of any of Examples 11-17, further comprising: initially deploying, configuring, updating, and reconfiguring the hidden services directory node, the at least one hidden service node, and the rendezvous point node using automated software.

[0114] Example 19 includes a method for operating a private onion routing network, the method comprising: receiving, at a directory authority node of the private onion routing network, identity information from a client computing device across at least one network; verifying, by the directory authority node, that the identity information received from the client computing device is associated with permissions to access a consensus file; and communicate the consensus file from the directory authority node to the client computing device across the at least one network.

[0115] Example 20 includes a method for operating a private onion routing network, the method comprising: receiving, by a node of the private onion routing network, identity information from a client computing device across at least one network; verifying, by the node, that the identity information received from the client computing device is associated with permissions to access the private onion routing network; allowing communication from the client computing device within the private onion routing network.

[0116] Example 21 includes a method comprising: downloading a network executable; adding a hidden service configuration pointing to an internet protocol address and a port of a hidden service node being protected; creating the hidden service node; identifying at least one introduction point node to be used by a client computing device to access the hidden servicenode; packaging relevant information regarding the at least one introduction point node and creating a descriptor for the hidden service node; and publishing the descriptor to a hidden service directory node.

[0117] Example 22 includes the method of Example 21, further comprising: downloading a most recent consensus at the client computing device; receiving an onion address from a user at the client computing device; communicating with the hidden service directory node using the client computing device to verify existence of the hidden service node; receiving the descriptor for the hidden service directory node at the client computing device; generating meeting rendezvous details at the client computing device using a one-time password and a rendezvous address for a rendezvous point node; sending meeting details from the client computing device to at least one introduction point received in the descriptor to establish a rendezvous point at the rendezvous point node to meet with the hidden service node; and receiving the one-time password at the client computing device from the hidden service node at the rendezvous point node.

[0118] Example 23 includes the method of Example 22, further comprising: receiving the meeting details from the at least one introduction point node at the hidden service node; approving the meeting details at the hidden service node; connecting the hidden service node to the rendezvous point node; and providing the one-time password from the hidden service node to the client computing device through the rendezvous point node for verification by the client computing device.

[0119] Example 24 includes a method comprising: receiving meeting details from introduction point at a hidden service; approving the meeting details at the hidden service; connecting the hidden service to a rendezvous point node; and providing a one-time password for verification by a computing device.

Claims

CLAIMSWhat is claimed is:

1. A private onion routing network comprising: a plurality of network nodes communicatively coupled by at least one network, the plurality of network nodes comprising: a plurality of relay nodes; at least one hidden services directory node; at least one hidden service node; at least one rendezvous point node; wherein the at least one hidden services directory node is configured to: receive identity information and an onion address for a hidden service from a client computing device across the at least one network; verify that the identity information received from the client computing device is associated with permissions to access the hidden service identified by the onion address; and communicate a descriptor for the hidden service to the client computing device across the at least one network, wherein the descriptor includes a rendezvous address for a rendezvous point node of the at least one rendezvous point node, wherein the rendezvous point node is where the client computing device meets with the at least one hidden service node.

2. The private onion routing network of claim 1, further comprising: wherein the plurality of network nodes further comprises: at least one introduction point node configured to: receive meeting rendezvous details from the client computing device, wherein the meeting rendezvous details include a one-time password and the rendezvous address for the rendezvous point node of the at least one rendezvous point node.

3. The private onion routing network of claim 2, wherein: the at least one hidden service node is configured to: receive the meeting rendezvous details from the at least one introduction point node;approve the meeting rendezvous details; connect the at least one hidden service node to the rendezvous point node of the plurality of network nodes; provide the one-time password to the client computing device through the rendezvous point node for verification by the client computing device; and establish a connection with the client computing device through the rendezvous point node.

4. The private onion routing network of claim 2, wherein: the at least one hidden services directory node is configured to: publish the descriptor of the at least one introduction point node based on relevant information regarding the at least one introduction point node.

5. The private onion routing network of claim 1, wherein the identity information comprises an identity token.

6. The private onion routing network of claim 5, wherein the identity token identifies a user of the client computing device.

7. The private onion routing network of claim 1, wherein the plurality of network nodes are initially deployed, configured, updated, and reconfigured using automated software.

8. A system comprising: a computing device configured to: receive an onion address for a hidden service from a user; communicate identity information and the onion address for the hidden service to a hidden service directory node across at least one network to verify existence of a hidden service node associated with the hidden service; receive a descriptor for the hidden service from the hidden service directory node across the at least one network, wherein the descriptor includes a rendezvous address for a rendezvous point node where the computing device meets with the hidden service node; generate meeting rendezvous details using a one-time password and the rendezvous address of the rendezvous point node;communicate the meeting rendezvous details to at least one introduction point node received in the descriptor to establish the rendezvous point node to meet with the hidden service node; and receive the one-time password at the computing device from the hidden service node at the rendezvous point node.

9. The system of claim 8, further comprising: circuitry configured to implement the hidden service node, the circuitry configured to: receive the meeting rendezvous details from the at least one introduction point node at the hidden service node; approve the meeting rendezvous details at the hidden service node; connect the hidden service node to the rendezvous point node; and provide the one-time password for verification by the computing device.

10. The system of claim 8, wherein the computing device is further configured to: download a most recent consensus at the computing device.

11. A method for operating a private onion routing network, the method comprising: receiving, by a hidden services directory node of the private onion routing network, identity information and an onion address for a hidden service from a client computing device across at least one network; verifying, by the hidden services directory node, that the identity information received from the client computing device is associated with permissions to access the hidden service identified by the onion address; communicating, by the hidden services directory node, a descriptor for the hidden service to the client computing device across the at least one network, wherein the descriptor includes a rendezvous address for a rendezvous point node, wherein the rendezvous point node is where the client computing device meets with at least one hidden service node of the private onion routing network.

12. The method of claim 11, further comprising: generating, at the client computing device, meeting rendezvous details using a onetime password and the rendezvous address for the rendezvous point node.

13. The method of claim 11, further comprising: receiving, by at least one introduction point node of the private onion routing network, meeting rendezvous details from the client computing device, wherein the meeting rendezvous details include a one-time password and the rendezvous address for the rendezvous point node.

14. The method of claim 13, further comprising: receiving, by the at least one hidden service node, the meeting rendezvous details from the at least one introduction point node; approving, by the at least one hidden service node, the meeting rendezvous details; connecting the at least one hidden service node to the rendezvous point node; providing, by the at least one hidden service node, the one-time password to the client computing device through the rendezvous point node for verification by the client computing device; and establishing, by the at least one hidden service node, a connection with the client computing device through the rendezvous point node.

15. The method of claim 13, further comprising: publishing, by the hidden services directory node, the descriptor of the at least one introduction point node based on relevant information regarding the at least one introduction point node.

16. The method of claim 11, wherein the identity information comprises an identity token.

17. The method of claim 16, wherein the identity token identifies a user of the client computing device.

18. The method of claim 11, further comprising: initially deploying, configuring, updating, and reconfiguring the hidden services directory node, the at least one hidden service node, and the rendezvous point node using automated software.

19. A method for operating a private onion routing network, the method comprising:receiving, at a directory authority node of the private onion routing network, identity information from a client computing device across at least one network; verifying, by the directory authority node, that the identity information received from the client computing device is associated with permissions to access a consensus file; and communicate the consensus file from the directory authority node to the client computing device across the at least one network.

20. A method for operating a private onion routing network, the method comprising: receiving, by a node of the private onion routing network, identity information from a client computing device across at least one network; verifying, by the node, that the identity information received from the client computing device is associated with permissions to access the private onion routing network; allowing communication from the client computing device within the private onion routing network.

21. A method compri sing : downloading a network executable; adding a hidden service configuration pointing to an internet protocol address and a port of a hidden service node being protected; creating the hidden service node; identifying at least one introduction point node to be used by a client computing device to access the hidden service node; packaging relevant information regarding the at least one introduction point node and creating a descriptor for the hidden service node; and publishing the descriptor to a hidden service directory node.

22. The method of claim 21, further comprising: downloading a most recent consensus at the client computing device; receiving an onion address from a user at the client computing device; communicating with the hidden service directory node using the client computing device to verify existence of the hidden service node; receiving the descriptor for the hidden service directory node at the client computing device;generating meeting rendezvous details at the client computing device using a one-time password and a rendezvous address for a rendezvous point node; sending meeting details from the client computing device to at least one introduction point received in the descriptor to establish a rendezvous point at the rendezvous point node to meet with the hidden service node; and receiving the one-time password at the client computing device from the hidden service node at the rendezvous point node.

23. The method of claim 22, further comprising: receiving the meeting details from the at least one introduction point node at the hidden service node; approving the meeting details at the hidden service node; connecting the hidden service node to the rendezvous point node; and providing the one-time password from the hidden service node to the client computing device through the rendezvous point node for verification by the client computing device.

24. A method comprising: receiving meeting details from introduction point at a hidden service; approving the meeting details at the hidden service; connecting the hidden service to a rendezvous point node; and providing a one-time password for verification by a computing device.

Images