WO2021253127A1

WO2021253127A1 - System and method for controlling network access

Info

Publication number: WO2021253127A1
Application number: PCT/CA2021/050830
Authority: WO
Inventors: Katherine SIAVICHAY; Jean-Denis BOUDREAULT; Maxime LEMONNIER; Frederic BOUDREAULT; Benjamin Bedard
Original assignee: Neuralia Technologies Inc.
Priority date: 2020-06-19
Filing date: 2021-06-17
Publication date: 2021-12-23

Abstract

Method and system network for controlling access includes a trusted node and validator nodes. Trusted node receives a validation request from a requesting node. For the validation request, a set of validator nodes is assigned, a validation appointment time window is defined, and a validation package is generated. The package includes security validation operations that are encrypted by a request-specific key. The package is made available prior to the start of the time window while the key is made available at the start of the window. The validation package is treated by the requesting node to generate a validation response package, which is received by the validator nodes. Each validator node further generates a node- specific timestamped response package based on the received validation response package. The timestamped packages are received at the trusted node, which then determines a validation approval decision for the requesting node based on these packages.

Description

SYSTEM AND METHOD FOR CONTROLLING NETWORK ACCESS

RELATED PATENT APPLICATION

The present application claims priority from U.S. provisional patent application no. 63/041 ,410, filed June 19, 2020 and entitled “SYSTEM AND METHOD FOR CONTROLLING NETWORK ACCESS”, the disclosure of which is hereby incorporated by reference in its entirety.

TECHNICAL FIELD

The present disclosure generally relates to systems and methods for validating a network node as being granted access to network functionalities, and more particularly the participation of validator nodes, which may be distributed and untrusted, in the validation of a requesting node for granting access.

BACKGROUND

The growth in popularity of new technologies for storing, managing and sharing data, such as the proliferation of blockchain technologies, raises additional concerns regarding how to effectively manage ecosystems implementing such technologies. An important concern is ensuring a stable ecosystem and guarding against bad actors. For example, the decentralized nature of various blockchain networks presents important benefits, but also raises the possibility for malicious activity.

In the case of blockchain networks, its surge in success has also given to a rise in bad actors, such as thieves, abusers and attackers. When a blockchain is public, it may work well under a reasonably load of users. But if it is to become successful in any way, a large surge of users may destabilize its ability to function correctly. Bitcoin is an example of this effect. Although it is financially successful, the general public have had difficulty accessing it. A rise in elite professional miners have increased the difficulty to mine to such high levels that a common user can no longer participate in mining bitcoins.

Malicious activity on a network can take various forms. For example, an excessive number of users or requests accessing key centralized servers can create an overload and cause the server to halt due to denial of service (DDOS). This DDOS creates a weak point that can be exploited. As another example, a surge in the amount of thieves on a network can reduce an ecosystems usability, and eventually bring an end to the ecosystem.

Accordingly, there is a need for networks to guard against malicious activity. One aspect of doing so is by controlling user access such that only legitimate actors have access and bad actors are kept out. A form of controlling access is by requiring a registering user to provide real-life identification, such as a phone number, passport, etc. Such an approach requires centralized control of the process of registering users and can also raise privacy concerns.

SUMMARY

According to one aspect, there is provided a method for validating a requesting node on network. The method includes: at a trusted node, receiving, a validation request from the requesting node, the validation request including a set of one or more public keys associated to the requesting node; at the trusted node, in response to receiving the validation request, assigning a set of one or more validator nodes of the network to the validation request, defining a validation appointment time window for the validation request and generating a validation package for the validation request, the validation appointment time window having a start time and a window duration, and the validation package including identifiers of the one or more validator nodes of the assigned sets, one or more security validation operations and being encrypted by a request-specific key; at the trusted node, prior to the start of the validation appointment time window, making available the validation package over the network; at the trusted node, at substantially the start time of the validation appointment time window, making available the request-specific key to the requesting node; at each of the validator nodes of the assigned set, receiving a validation response package generated by the requesting node from treating the one or more security validation operations included in the validation package; at each of the validator nodes of the assigned set, generating a node specific timestamped response package based on the received validation response package and a timestamp of receipt of the validation response package, and transmitting the node-specific timestamped response package to the trusted node; at the trusted node, in response to receiving the node-specific timestamped response package from each of the validator nodes of the assigned set, determining a validation approval decision for the requesting node based on the node-specific timestamped response packages received from the validator nodes; and at the trusted node, if the validation approval decision is positive, registering the requesting node as having a validated status on the network and storing the public keys associated to the validated requesting node at the trusted node.

According to another aspect, there is provided a network comprising network nodes configured to carry out the steps according to method described herein according to various example embodiments.

According to another aspect, there is provided an access-controlled network system comprising a trusted computing node. The trusted node is configured for: receiving a validation request from a requesting node, the validation request including a set of one or more public keys associated to the requesting node; in response to receiving the validation request, assigning a set of one or more validator nodes of the network to the validation request, defining a validation appointment time window for the validation request and generating a validation package for the validation request, the validation appoint time window having a start time and a window duration, and the validation package including identifiers of the one or more validator nodes of the assigned sets, one or more security validation operations and being encrypted by a request-specific key; prior to the start of the validation appointment time window, making available the validation package over the network; at substantially the start time of the validation appointment time window, making available the request-specific key to the requesting node; receiving a node-specific timestamped response package from each of the validator nodes of the assigned set; in response to receiving the node-specific timestamped response package from each of the validator nodes of the assigned set, determining a validation approval decision for the requesting node based on the node-specific timestamped response packages received from the validator nodes; and if the validation approval decision is positive, registering the requesting node as having a validated status on the network and storing the public keys associated to the validated requesting node at the trusted node.

The system may further include a plurality of validator computing nodes, the assigned set of validator nodes being selected from the plurality of validator computing nodes, each validator node being configured for: receiving the validator response package generated by the requesting node from treating the one or more security validator operations included in the validation package; generating a respective node-specific timestamped response packaged based on the received validation response package and a timestamp of receipt of the validation response package; and transmitting the respective node-specific timestamped response package to the trusted node. BRIEF DESCRIPTION OF THE DRAWINGS

For a better understanding of the embodiments described herein and to show more clearly how they may be carried into effect, reference will now be made, by way of example only, to the accompanying drawings which show at least one exemplary embodiment, and in which: Figure 1 illustrates a schematic diagram of a validation-enabled network according to an example embodiment;

Figure 2 illustrates a flowchart showing the exchange of information between a requesting node and the validation-enabled network according to an example embodiment;

Figure 3 illustrates a schematic diagram showing the components for building a validation package according to an example embodiment;

Figure 4 illustrates the flow of data between various nodes of the validation- enabled network according to an example embodiment; Figure 5 illustrates a schematic diagram of a list of assigned validators included within a validation package according to an alternative example embodiment;

Figure 6 illustrates a schematic diagram of the exchange of information between a requesting node and its associated validator nodes according to the alternative example embodiment;

Figure 7 illustrates a schematic diagram of the contents of a validation package of the validator nodes according to a modification of the alternative example embodiment;

Figure 8 illustrates a flowchart of the data flow between a requesting node and its assigned validator nodes according to the modification of the alternative example embodiment;

Figure 9 illustrates a schematic diagram of a list of assigned validator nodes included in a validation package according to a simplified alternative example embodiment; and Figure 10 illustrates a flowchart of the dataflow between a requesting node and its assigned validator nodes according to the simplified alternative example embodiment. It will be appreciated that for simplicity and clarity of illustration, elements shown in the figures have not necessarily been drawn to scale. For example, the dimensions of some of the elements may be exaggerated relative to other elements for clarity. DETAILED DESCRIPTION

It will be appreciated that, for simplicity and clarity of illustration, where considered appropriate, reference numerals may be repeated among the figures to indicate corresponding or analogous elements or steps. In addition, numerous specific details are set forth in order to provide a thorough understanding of the exemplary embodiments described herein. However, it will be understood by those of ordinary skill in the art, that the embodiments described herein may be practiced without these specific details. In other instances, well-known methods, procedures and components have not been described in detail so as not to obscure the embodiments described herein. Furthermore, this description is not to be considered as limiting the scope of the embodiments described herein in any way but rather as merely describing the implementation of the various embodiments described herein.

In general terms, the methods and systems described herein according to various example embodiments involve validating a user account registered to a network in a decentralized manner while providing sufficient safeguards against malicious activities. The validation operates by requiring a requesting node associated to the user account to perform one or more security validation operations within a validation appointment time window having a defined duration and having one or more validator nodes on the network verify performance of these operations by the requesting node. Security concerns are addressed by, among others, requiring the requesting node to perform security validation operations, constraining the time interval in which such operations can be performed, and using validator nodes to verify the performance, the last factor allowing for building a consensus decision. Further details are provided elsewhere herein. Referring now to Figure 1 , therein illustrated is a schematic diagram of a validation-enabled network 1 according to an example embodiment. The validation-enabled network 1 is illustrated in Figure 1 as a peer-to-peer network and details are provided herein with reference to such a type of network. The peer- to-peer network can use a gossip protocol such that each node can communicate with other nodes in a viral manner. Flowever, it will be understood that various embodiments described herein are not to be limited to a peer-to-peer network. Systems and methods described herein can also be applicable to other types of networks (ex: having different network protocols and topology) with appropriate modifications. Such other types of networks can include a network having http(s) web services, or a combination of different network types.

The validation-enabled network 1 includes a plurality of interconnected nodes, each representing a computing device (or a group of computing devices) connected to the network. As illustrated, the validation-enabled network 1 includes at least one trusted node 8, one or more validator nodes 16, and at least one requesting node 24. Each type of node performs a respective set of functions and exchanges of information with other nodes to permit validation of new user accounts on the network 1 . As described elsewhere herein, such validation of new account users can be carried out in a substantially decentralized manner according to various example embodiments.

A requesting node 24 corresponds to a computing device connected to the network being used by a user that desires to access functionalities provided by the given validation-enabled network. The user can represent a real-world entity such an individual or an organization. Functionalities provided by the validation-enabled network can include the exchange of information and/or financial items. For example, in a blockchain-based validation-enabled network 1 , functionalities can be related to cryptocurrencies, smart contracts, financial services, securities trading and supply chain management. Given the importance these functionalities, users of the network would want access of these functionalities to be restricted to legitimate users, hence the need for requiring the validation that the users are not potential bad actors prior to granting access to these functionalities. The terms “requesting user” and “requesting node” are used herein interchangeably, but it will be understood that the requesting node will always be associated to a given user having a specific identity. However, so long as the user provides the proper identifier, the user may access the network using different computing devices, which may correspond to different actual nodes on the network. In this case, the requesting node 24 refers to any node linked to a computing device used by the specific requesting user accessing the validation- enabled network 1.

In one example, the requesting node 24 can be identified by at least one private/public cryptographic key pair associated to the requesting user, whereby the public key is provided to the validation-enabled network 1 and the private key is retained by the requesting node 24. As is known in the art, the requesting user can cryptographically sign any of their communications using the private key, which can then be decrypted by its paired public key, thereby allowing other users on the network to verify that the communication originated from the given requesting user. All activities by the given requesting user account will be associated to the given private/public key pair and/or another unique ID assigned to user (such as upon validation of the user account). It will be understood that the requesting user can provide a plurality of sets of private/public cryptographic key pairs, wherein any one of the public keys can be used to identify that user.

Within the validation-enabled network 1 , the requesting node 24 can have one of at least a non-validated state and a validated state. In the non-validated state, the requesting node 24 has limited access to the functionalities provided by the validation-enabled network 1. By contrast, in the validated state, the requesting node 24 can have an expanded access to functionalities provided by the network 1. For example, only in the validated state can the requesting node 24 perform essential and/or critical informational and/or financial transactions on the validation-enabled network 1. The process for validating the requesting node 24 so that it can acquire the validated state is described further herein. One or more trusted nodes 8 are nodes that have a sufficient level of trust so as to be allowed to perform critical operations related to the granting and revoking of validated status to requesting nodes 24. The trusted node 8 is configured to maintain databases that track the status of user accounts (non- validated nodes and validated nodes), the statuses of pending validation requests on the validation-enabled network 1 , and the status of validator nodes 16 available for performing validation-related operations. As illustrated in Figure 1 , the trusted nodes 8 maintain an account registry 32 that stores all of the user accounts 24 registered to the network and whether each account has a validated or non- validated status. A public keys registry 40 stores the sets of private/public keys associated to each user account 24 stored in the account registry 32. A validator nodes registry 48 stores a list of entries identifying nodes 16 on the network 1 that are available to be assigned to carry out validation operations in response to a validation request from a given requesting node 24. An appointments registry 56 stores information regarding ongoing validation requests. As described elsewhere herein, each validation request includes identifying the requesting node 24 making the request, the validation appointment time window selected for the request, and the set of one or more validator nodes 16 assigned to perform validation operations assigned to the request. The trusted node 8 is also operable to generate the validation package used during the validation request. According to various example embodiments, the trusted node 8 has a sufficient trust level to be allowed to change the status of any requesting node 24 from non-validated to validated.

Validator nodes 16 are specialized nodes within the network that are enabled to perform validation-related functions. As described elsewhere herein, the validator nodes 16 receive validation response packages from a requesting node 24, timestamps this receipt and prepares a timestamped response package to the trusted node(s) 8. The validator nodes 16 can also be configured to verify proof of treatment of security validation operations by a requesting node 24 and the timely providing of this treatment. Where the validation-enabled network 1 is a peer-to-peer gossip network, the validators nodes 16 can be randomly spread across the network. The validator nodes 16 are whitelisted to perform validation- related functions and are identified as such in the validator nodes registry 48. The validators nodes 16 generally need to remain available within the network (ex: being online) and be in a constant ready to participate in a timely manner in the validation process. According to various example embodiments, validator nodes 16 do not need to be trusted because a plurality of validator nodes can participate in a single validation request and the ultimate decision to validate any requesting node is made based on a consensus of responses from the validator nodes. It will be appreciated that this consensus process can eliminate or override bad acting validator nodes.

Each validator node 16 can include a respective validation cache 64 for storing data related to ongoing validation requests to which the given validator node 16 is assigned.

While the trusted node(s) 8 maintains a list of available validator nodes 16 in the validator nodes registry 48, validator nodes 16 may be required to periodically notify the trusted node(s) 8 of their status as being available to perform validation tasks. Accordingly, validator nodes 16 act as servers and will open a network port so that they can be contacted when needed for validation services. If a given validator node 16 becomes unavailable (ex: becomes offline) and fails to periodically notify the trusted node(s) 8 of its availability, it may be removed from the validator nodes registry 48.

Referring now to Figure 2, therein illustrated is a flowchart showing the exchange of information between a given requesting node 24 (which may be represented by an initiating device) and the validation-enabled network 1 according to an example embodiment.

A requesting node 24 initiates the process of requesting validation so as to obtain the validated status on the validation-enabled network 1. The validation process can be preceded by an account creation process, which includes the requesting user providing identification information, such as the sets of public/private keys for that requesting user. The requesting user is initially presumed to be untrusted and potentially malicious. Accordingly, a created user account is initially attributed the non-validated status. The non-validated status must be validated by undergoing the validation process. The creation of a user account and the validation process can be carried out in a single procedure.

In various example embodiments, a validated user account may be required to renew its validated status. Re-validation can be carried out in the same manner as validation for a newly created user account.

The description herein made with reference to one instance of validating a requesting node 24, and generally refers to a single validation request by a single requesting node 24. However, it will be understood that in practice, a plurality of requesting nodes 24 can make validation requests concurrently, each validation request being carried out as described herein.

Within an instance of a validation process for one requesting node 24, the requesting node 24 transmits a validation request 72 onto the validation-enabled network 1 . The validation request 72 includes an appointment request message. Where the validation request 72 is made at the same time as an account creation request, the set of public key(s) linked to the user account can also be included. The set of public keys are linked to the account’s private keys, which are stored in a private store 80, such a digital wallet.

According to one example embodiment, performance of a rate-limiting operation is required in order to create the user account and/or initiate the validation request 72. The rate-limiting operation ensures that the request is not being made by an automated computing script (ex: a bot, intending to create new accounts at a high frequency). For example, the operation seeks to ensure that a human user is interacting with the computing device initiating the validation request. The rate limiting operation can be a puzzle solvable only by a human (ex: captchas), a secondary human interaction (ex: phone call, text message) or a compute-intensive task, or a combination of these. As is known in the art, the rate limiting operation seeks to make the performing of the rate-limiting operation inefficient for non-humans. The validation request 72 can include proof of performance of the rate-limiting operation. The transmission of the validation request 72 to the validation-enabled network 1 makes the validation request 72 available to other nodes on the network 1 , which may include a suitable communications network 74 (ex: Internet). Accordingly, a trusted node 8 on the validation-enable network 1 receives the validation request 72.

Upon receiving the validation request 72, the trusted node 8 verifies that the validation request 72 is complete. For example, the trusted node 8 verifies that the proof of the performance of the rate limitation operation is proper. If the validation request 72 is complete, the trusted node 8 continues the validation process.

In response to receiving, a completed validation request, the trusted node 8 creates an entry within the appointment registry 56 to track the validation request. The trusted node 8 also defines a validation appointment time window for the validation request. The validation appointment time window defines a start time and a window duration. Further operations required by the requesting node 24 as part of the validation process are to be performed during the validation appointment time window, i.e. after the start time and before the expiry of window duration. The start time is a time point in the future (ex: 10:00AM tomorrow) and the window duration is set to be sufficiently short to provide appropriate security safeguards (ex: approximately 60 seconds).

The trusted node 8 prepares an appointment confirmation 88 that includes the appointment details (ex: start time and window duration) and makes the appointment confirmation available to the requesting node 24. The appointment confirmation may also contain an appointment identifier that is uniquely associated, on a network-wide basis, to the given validation request 72. The appointment confirmation 88 can be encrypted using a public key associated to the requesting node so that it can be decrypted by its paired private key. Within the validation process, no further action is required by the requesting node 24 until the approach of the start time of the validation appointment time window.

In response to receiving the validation request 72, the trusted node 8 also prepares a validation package 96 (FIG. 3). This validation package 96 is prepared ahead of the start time of the appointment time window. For example, the validation package 96 can be prepared ahead of the start time by a time of interval ranging from a few minutes to a few hours. The validation package includes one or more security validation operations that need to be completed by the requesting node 24 within the validation appointment time window.

The security validation operations require treatment by the requesting node 24 in a way that restricts any automated processing by the requesting node 24 with the goal of limiting the general ability by bad actors to create accounts at a high frequency. The security validation operations can be any trial or limiting factors that process of validation more difficult to complete. These operations can include multiple requirements to filter out bad actors. The security validation operations can include one or more compute-intensive tasks that need to be carried out by the requesting node 24 to generate correct response(s). The security validation operations can also include one or more human-solvable puzzles requiring human interaction to provide correct response(s). A combination of different security validation operations can be included in the validation package. The combination can be varied in different validation packages prepared by the trusted node(s) 8 for different validation requests to reduce the opportunity for bad actors to automate the process of treating the security validation operations, such as by learning automated scripts. A plurality of security validation operations can be included in the validation package and the requesting node can be assigned a combination formed of a subset of these operations in away that is specific to that node. For example, where multiple validation requests are ongoing at the same time (ex: have a same validation appointment time window), the same combination of security validation operations can be included in the validation packages made available to each of these requesting nodes. Flowever, the requesting nodes can each be assigned a different subset of security validation operations from this combination. Additionally, or alternatively, each requesting node can be given different inputs for treating their respective security validation operations, which affect the answer to these operations for each node. Continuing with the description for the single instance of validation for a given validation request, the security validation operations are packaged into the validation package and is strongly encrypted. The validation package can be encrypted by a request-specific key that is generated specifically for the given validation request. For example, the validation package is encrypted using a symmetrical encryption algorithm. The encryption of the validation package allows the package to be made available (i.e. distributed) over the validation-enabled network 1 , but that the contents (i.e. set of the security validation operations) are not accessible without the request-specific key. Accordingly, access to the contents can be controlled and only granted at a later point in time, namely at or immediately prior to the start time of the validation appointment time window.

Once the validation package is generated for the given validation request, the trusted node 8 makes the validation package available prior to the start of the appointment time. In this way, the requesting node 24 can obtain (ex: download) the validation package ahead of the start time of the validation appointment time window. The making available of the validation package ahead of the start time avoids any delays that may be caused due to the requesting node 24 having to otherwise download the validation package during the validation appointment time window, which can affect the requesting node’s ability to complete treatment of the security validation operations before the expiry of the window duration.

The request-specific key is provided at substantially the start time of the validation appointment time window. The key provided at the moment of the start time or immediately ahead of the start time, thereby only granting access to the validation package 96 with little to no lead time ahead of the validation appointment time window. Accordingly, the validation security operations contained in the validation is also accessible at substantially the start time of the validation appointment time window.

As described above, the validation package is first made available over the network 1 without concurrently making available the request-specific key. That is, the validation package 96 is made available before the request-specific key is made available. Therefore, although the requesting node 24 has obtained the validation package, it must wait until the request-specific key is received to access the contents of the validation package. Since the request-specific key is provided at substantially the start time of the validation appointment time window, it will be appreciated that this temporal restriction of access forces the requesting node 24 to treat the validation security operations within an interval of time that starts at substantially the same time as the start time of the validation appointment time window. Importantly, the treatment of the validation security operations well ahead of the validation appointment time window is prevented. This constraint restricts the proliferation of new accounts. It will be appreciated that this restriction curbs high frequency creation of new accounts by requiring the requesting user to dedicate human attention and/or computing resources at specific time periods and restricting the opportunity to prepare for treatment of security operations ahead of the validation appointment time window.

It will be appreciated that the validation package is made available prior to the start time of the appointment time window by a length of time that is non-critical for security concerns. Since the validation package is encrypted, it can be made available well ahead of the start time.

By contrast, the request-specific key must be made available at or immediately prior to the start time of the validation appointment time window by a length of time that is critical for security concerns. In particular, the request-specific key is made available at a point of time sufficiently close in time to the start time of the validation appointment time window so that the requesting node 24 in effect can only access the validation security operations during the validation appointment time window.

The validation appointment time window seeks to restrain the time duration in which the requesting node can perform certain actions required for validation. Where the trusted node 8 responds to multiple validation requests that are taking place at the same time, it may be configured to schedule the validation appointment time windows of these requests to occur at the same time. Accordingly, resources (human or computing) will be deployed in parallel within this same time window to complete validation. This restricts the ability of bad actors to create user accounts or perform other rate-limited operations by deploying these same resources in a serial manner over an extended time duration.

In response to receiving the validation request, the trusted node 8 also assigns a set of one or more validator nodes 16 of the network 1 to the validation request. The assigned set of validator nodes perform validation operations for the given validation request. Each of the validator nodes 16 of the assigned set are expected to log certain timestamps that can be used to verify that the security validations operations have been successfully treated by the requesting node 24 within the validation appointment time window. The validation package generated for a given validation request and transmitted to the requesting node 24 also includes a set of validator entries that include identifiers of the set of validator nodes 16 assigned to the given validation request. Each validator entry may include additional information to permit communication between the requesting node 24 and the validator node 16 identified in the validator entry. Such additional information can include IP addresses, ports, and other keys and tokens used for secured communication with each of the identified validator nodes 16. The assignments of the validator nodes 16 to validation requests can be stored and tracked in the validators nodes registry 48 and/or the appointment registry 56.

Referring now to Figure 3, therein illustrated is a schematic diagram showing the components for building a validation package 96 according to an example embodiment. In the example illustrated in Figure 3, a plurality of validation packages corresponding to a plurality of validation requests are combined within a single validation bundle 112.

The plurality of requesting nodes 24 involved in the plurality of ongoing validation requests are listed. In the illustrated example, there are at least 3 validation requests having been made by 3 requesting nodes identified as “Applicant 1”, “Applicant 2” and “Applicant 3”. For each validation request and requesting node, a respective set of validator nodes 16 has been assigned (“Validators A, B, C” for “Applicant 1”, “Validators D, E, F” for “Applicant 2”, and “Validators C, E, G” for “Applicant 3”). It will be appreciated that the same validator node 16 can be assigned to multiple validation requests. Security validation operations are also included in the validation bundle 112. In the illustrated example, the security validation operations include human solvable puzzle games 128 intended to be solved by a human user and compute-intensive tasks 136 requiring use of substantial computing work to solve.

According to the example illustrated in Figure 3, where a plurality of validation requests are received, the trusted node(s) 8 prepare a validation package 96 for each validation request and makes the validation packages available together and at the same time within a single validation bundle 112 (Figure 3 illustrates an example of this). Each respective subset of the data within the validation bundle 112 pertaining to any given one requesting node/validation request is encrypted so that it is only accessible to that relevant requesting node 24. This subset of data can be decrypted by the given requesting node 24 using access elements 104 that is available only to that requesting node, such as the unique appointment identifier, one of its private keys, or its request-specific key. For example, the access elements 104 available only to that requesting node 24 can be used to access the list of validator nodes 16 assigned to its own validation request, but cannot be used to access the list of validator nodes 16 assigned to other validation requests. Accordingly, when a given requesting node receives its respective validation package 96, it actually receives a validation bundle 112 that includes data pertaining to multiple validation request, but its access is limited to data pertaining to itself. Furthermore, in any cases, access to the security validation operations (ex: 128, 136) will also be restricted until the request-specific key is received immediately prior to the start time of the validation appointment time window. The validation bundle 112 is compressed and encrypted as appropriate (to restrict access to any requesting node only to information associated to that node) and is further strongly encrypted using the request- specific key. It will be appreciated that this provides a container for the validation package 96 that is made available to the requesting nodes 24. The security validation operations 128, 136 within the validation bundle 112 can be the same for each of the requesting nodes identified in the bundle. Alternatively, and as described elsewhere herein, each requesting node 24 can be assigned its own specific sub-combination of security validation operations to be treated in its respective validation request.

As described, herein the given requesting node 24 initiates the validation process by making the validation request 72 over the validation-enabled network 1. In response to receiving the request, the trusted node 8 provides an appointment identifier, which is received by the requesting node 24. The requesting node 24 also receives information pertaining to the validation appointment time window, which may be part of the confirmation containing the appointment identifier. The trusted node 8 further generates the validation package 96, which is also received by the requesting node 24. As further described, the requesting node 24 is not required to take any action until the arrival of the start time of the validation appointment time window.

The requesting node 24 takes action again at substantially the start time of the validation appointment time window (at or immediately prior to the start time). At this time, it is expected that the request-specific key for accessing the security validation operations 128, 136 will become available and the requesting node 24 enters a listening state (if not already in this state) to receive the request-specific key. When available, the requesting node 24 receives the request-specific key.

Upon receipt of the request-specific key, the requesting node 24 decrypts the security validation operations using the request-specific key to gain access thereto. The requesting node 24 treats the one or more security validation operations included in the decrypted validation package. In order to obtain successful validation, treatment of the security validation operations must be completed, and proof of the treatment must be transmitted to the validator nodes 16 of the set assigned to the validation request within the validation appointment time window. The treatment of the security validation operations may involve human interaction by a human user associated to the requesting node/account 24. For example, the human user can interact with a computing device associated to the requesting node 24 to solve human-solvable puzzle(s) that are part of the security validation operations. The solution(s) obtained from the human user interaction provide proof of treatment of the security validation operations.

The treatment of the security validation operations may involve the computing device associated to the requesting node 24 contributing computing resources to solve the compute-intensive tasks that are part of the security validation operations. The solution(s) obtained from the performance of the compute-intensive tasks also provide proof of treatment of the security validation operations.

Upon completion of the treatment of the security validation operations, the requesting node 24 generates a validation response package that includes the proof of the treatment of the security validation operations. The requesting node 24 then transmits the validation response package to each and every validator node 16 of the assigned set associated to the validation request. The identifiers of the validator nodes 16 associated to the validation request can be listed within the validation package received earlier from the trusted node 8. The requesting node 24 may proceed to decrypt the list of identifiers of the validator nodes 16 assigned to it only after completing treatment of security validation operations. Alternatively, it may decrypt the list of identifiers at an earlier point in time.

After the transmitting the validation response packages to each of the validator nodes assigned to the validation request, the requesting node 24 will have completed its required tasks within the validation process. The requesting node 24 then waits to be notified of whether its request has been verified as being successful and that it has been granted the validated status on the validation- enabled network 1.

For the given ongoing validation request, each validator node 16 assigned by the trusted node 8 to the validation request is expected to be in a ready state to receive the validation response package from the requesting node 24 within the validation appointment time window. However, one or more validator nodes 16 of the assigned set may be unavailable during the validation appointment time window. The requesting node 24 therefore transmits the validation response package it has prepared to each of the available validator nodes 16 of the assigned set. The description herein refers to operations performed at one validator node 16 or at each validator node 16 of the assigned set, and it will be understood that such description refers to operations performed at an available validator node 16. Furthermore, it will be understood that the operations performed at one of the available validator nodes 16 is also repeated at each of the available validator nodes 16 but that the results of the performance of the operations at any given validator node 16 may vary from the results of another validator node 16. This difference may be caused by a difference in validator node configuration and/or particularities of the network configuration. According to one example embodiment, a validator node 16 is in a constant ready state to receive a validation response package from any given requesting node 24. For example, it may only need to be aware of when validation appointment time windows have been scheduled and be available during those time windows. According to another example embodiment, when responding to a validation request and assigning the set of validator nodes 16 for that request, the trusted node 8 can also contact the validator nodes of that assigned set to inform of the assignment. This can allow the validator node 16 to control from which requesting nodes 24 it receives a validation response package, which may be useful for controlling fraud.

After the validation response package has been transmitted by the requesting node 24, each given one of the (available) validator nodes 16 of assigned set receives a copy of the validation response package. The given validator node 16 may return a confirmation to the requesting node 24 to indicate that the validator node 16 is online and that the validation response package has been received by it.

The validator node 16 records the timestamp at which the validator node 16 received the validation response package. This timestamp is useful in determining whether the validation response package was received in a timely manner. It will be understood that within the set of validator nodes assigned to a given validation request, each validator node 16 independently records the moment that that given node 16 received the validation response package in its own respective timestamp.

The validator node 16 also stores the received validation response package in its cache 64.

The validator node 16 then generates a node-specific timestamped response package including the received validation response package and its record receipt timestamp.

According to various example embodiments, the available validator node 16 can be configured to verify that the validation response package contains proof of treatment of at least a portion of the security validation operations by the requesting node 24. For example, the validator node 16 can carry out the same treatment of the relevant portion of the security validation operations and then compare the solutions it generated from this treatment against the proof provided by the requesting node 24 in the received validation response package. For example, the validator node 16 can carry out the one or more compute-intensive tasks that form part of the security validation operations. Based on the verification, the validator node 16 generates a verification result indicating whether adequate proof of treatment of the security validation operations is provided in the received validation response package for the relevant portion of the security validation. It will be appreciated that having the validator node 16 perform this verification achieves better distribution of computing load across the network 1 when compared with having the trusted node performing this verification. The validator node 16 also records the timestamp at which the validator node 16 received the validation response package. According to example embodiments in which the validator node 16 does not perform any verification that the validation response package contains proof of treatment, the validator node 16 simply repackages the validation response package (received from the requesting node 24) and its record receipt timestamps to generate the timestamped response package.

The validation response package is considered to be provided in a timely manner if it is received at a point time within the validation appointment time window (i.e. before the expiry of the window time duration after the start time of the validation appoint time window). In an alternative example embodiment, as described in further detail herein, a slight shift in the validation appointment time window is implemented at the validator node level to account for transmission delays that may occur.

The timestamped response package is node-specific in that it is specific to that given validator node 16 that generated it and that recorded the timestamp included in it. Since the receipt timestamp is independently recorded, each validator node 16 will produce its own timestamped response package specific to that validator node 16. These validation scores may vary due to differences in node configuration and/or network configuration.

The validator node 16 (and each validator node 16 of the assigned set) transmits its node-specific timestamped response package for the given ongoing validation request to the trusted node(s) 8 for further processing.

According to various example embodiments, each validator node 16 can implement a respective delay between the point in time it receives the validation response package and later point in time at which the timestamped response package is transmitted to the trusted node(s) 8. Each validator node 16 can implement a respective delay of random length between these two moments in time. This delay can reduce the possibility of overloading the network (or any trusted node 8 specifically) due to many validator nodes 16 simultaneously transmitting their respective timestamped response package to the trusted node 8 at the same time. According to various example embodiment, each validator node 16 is also registered within the validation-enabled network 1 as a validated node. Accordingly, each validator node 16 stores a set of one or more private keys and has a corresponding set of paired public keys registered at the trusted node(s) 8. Accordingly, the timestamped response package transmitted by the validator node 16 to the trusted node 8 can be cryptographically signed with that validator node’s private key. This cryptographic signature allows the trusted node 8 to confirm that the timestamped response package is truly transmitted from the registered validator node 16. Where the identity of the validator node 16 is confirmed, the trusted node 8 stores the received timestamped response package. Where the cryptographic check fails for a given validator node 16, the trusted node 8 ignores and discards the timestamped response package from that validator node 16.

The trusted node(s) 8 receives the node-specific timestamped response package from each of the validator nodes 16 for the given validation request. Where a delay is implemented at the validator nodes 16, an interval of time corresponding to the longest of these delays passes before the trusted node 8 receives the timestamped response package from all of the validator nodes 16 assigned to the given validation request.

The trusted node(s) 8 further determines validation approval decision for the requesting node 24 based on the received node-specific timestamped response packages from the validator nodes 16. The trusted node 8 can decide to approval or reject validation of the requesting node 24 based on an aggregation of the timestamped response packages from the validator nodes 16. For example, the trusted node 8 may establish a consensus from the aggregate of the proof of treatment of the security validation operations contained in the timestamped response packages. The decision to approve the requesting node 24 depends on whether the aggregation of the timestamped response packages indicate that the requesting node 8 correctly completed treatment of the validation security operations and provided the timestamped response packages containing proof of this treatment in a timely manner to the validator nodes 16 assigned to the validation request. Where the validation approval decision is positive, the trusted node 8 registers the requesting node 24 as having a validated status on the validation- enabled network 1 . This change in status can be registered in the account registry 32 at the trusted node 8. The trusted node 8 further transmits a notification to the requesting node 24 informing the requesting node 24 that it has been granted the validated status. The requesting node 24 is then granted access to a fuller array of functionalities on the network 1 that come with the validated status. According to one example embodiment, the now-validated user node can be attributed a special unique ID by the trusted node 8 to indicate that the user account associated to the requesting node 24 has the validated status when carrying out functionalities and transactions on the validation-enabled network 1 .

The trusted node 8 arrives to a negative validation approval decision if the aggregate of the timestamped response packages indicate that the requesting node 24 failed the validation process. The validation process can be failed by not correctly treating the security validation operations. For example, one or more of the human-solvable puzzles was answered incorrectly and/or the compute intensive tasks was processed incorrectly. The validation process can also be failed by not providing the validation response packages in a timely manner to the validator nodes 16 assigned to the validation response, for example, the human user was not present to answer the human solvable puzzles within the validation appointment time window. Another validation appointment time window can then be defined to allow another attempt for validation. Alternatively, or additionally, a secondary authentication method can be used, which may include methods commonly known in the art.

According to various example embodiments, the validation status granted by the trusted node 8 is time-limited. For example, a new validation status can have a duration for a time interval of a period of about a month. Upon the expiry of predetermined validity time interval, the validation status for the given validated node 24 is revoked by the trusted node 8. When nearing expiry, or upon expiry, the trusted node 8 can transmit a prompt to the validated node 24 to renew its validation status. The renewal of the validation status can include carrying out the same validation process as described herein.

It will be appreciated that having to periodically renew the validated status is a minor burden on the user to maintain the validated status. A user may have to periodically solve a puzzle and/or perform a set of compute-intensive tasks in exchange for this validated status, but also gains in ensuring that bad actors are filtered out from the network. Even if bad actors can manage to create a few bad accounts by using various dubious means, they will not be able to accumulate their efforts, as after a time period, the accounts verification will reset, and the effort of re-verifying these accounts uses the resources they would need to validate new ones. This limits the proliferation of bad actor accounts and renders the registration process very unpleasant and difficult for attackers, while being a minor burden on regular users.

Referring now to Figure 4, therein illustrated is schematic diagram showing the flow of data between various nodes of the validation-enabled network 1 according to an example embodiment. The example of Figure 4 shows the flow of data after the requesting node 24 has completed its treatment of the security validation operations contained in the security validation package that it received. After completing the treatment of the security validation operations and preparing the validation response package 144, the requesting node 24 sends the validation response package 144 to each of the validator node 16 assigned to its validation request. In the illustrated example, two of the validator nodes 16 are assigned to the given validation request and the requesting node 24 transmits its validation response package 144 to these validator nodes 16. A third validator node 16 is not assigned to this validation request and does not receive the validation response package 144.

Each of the two assigned validator nodes 16 processes the validation response package by recording a respective node-specific timestamped response package 148 and storing the received validation response package in its validation cache 64. The validator node 16 may also carry out treatment of a portion of the security validation operations for the validation request and compare the solution to this treatment against the proof of treatment contained in the received validation response package, and further produce a verified result. The verified result can also be stored in the validation cache 64.

The example of Figure 4 shows that each validation request can be assigned a different set of validator nodes 16. One of the validator nodes 16 is participating in three ongoing verification results and has three current verification results in its cache 64. The other of the validator nodes is only participating in one ongoing verification result and has a corresponding one current verification result in its cache.

Each validator node 16 combines the received validation response package and the receipt timestamp for given validation request into a node-specific timestamped response package 148 and transmits this package to the trusted node 8. Where the validator node 16 also verifies the proof of the treatment to produce a verified result, the timestamped response package can also include the verified result. As described elsewhere herein, the validator node 16 may wait a node-specific delay before sending the timestamped response package 148 to the trusted node 8. Each validator node 16 prepares and transmits its own timestamped response package 148.

The trusted node(s) 8 receives an aggregate of the timestamped response packages 148 from the validator nodes 16. The example of Figure 4 illustrates the trusted node 8 receiving an aggregated package 152 from the two validator nodes 16, the aggregated package 152 being formed from the timestamped response packages 178 transmitted from each of the validator nodes 16 of the assigned set. The trusted node 8 then determines a validation approval decision based on consensus calculated from evaluating the aggregate response package.

As described elsewhere herein, according to an alternative example embodiment, a slight shift in the validation appointment time window is implemented at the validator node level to account for transmission delays that may occur. It was observed that implementing a global validation appointment time window, i.e. a single same appointment time window defined by a single time source that is then used by all of the validator nodes can be unfair in some network configurations. In some networks where latency is higher, that latency effectively reduces the duration of the validation appointment time window in which the requesting node must complete its treatment of the validation security operations. For example, if a validation appointment time window is 60 seconds long, but that there is a network latency of 40 seconds between the time that the request-specific key is made available by the trusted node 8 and the time that the key is actually received by the requesting node 24, then the requesting node 24 will only have 20 seconds to complete treatment of the validation security operations. Where the validation security operations include a human-solvable, the human user would only have 20 seconds to solve the puzzle.

One option is to allocate, in a global manner, more time in the validation appointment time window, i.e. having a longer time window duration. However, expanding the validation appointment time window also increases the opportunity for bad actors to carry out malicious activities.

According to the alternative example embodiment, the requesting node 24 can timestamp the moment that it is ready to begin treatment of the validation security operations. Since the requesting node 24 and the validator nodes 16 can all be untrusted, sufficient safeguards need to put in place to ensure that the nodes only access relevant information and only at relevant points in time.

As described elsewhere herein, each validator node 16 registers with the trusted nodes 8 a respective public key that is paired to a private key belonging to that node and that can be used to encrypt communications to and from that node. Furthermore, in response to receiving the validation request from a requesting node 24, the trusted node 8 prepares the validation package 96 having the list of validator nodes 16 assigned to the specific validation request and the security validation operations. The trusted node 8 transmits the validation package 96 to the requesting node 24. Where the validation package 96 is transmitted as part of a validation bundle 112 containing validation packages 96 for a plurality requesting node 24, each requesting node 24 possesses only access elements 104 for accessing information pertaining to its own validation request. A given requesting node 24 can access only its own list of validator entries identifying its set of assigned validator nodes 16 (ex: using the unique appointment identifier, its private keys, or its request-specific key) and can access only its set of security validation operations using the request-specific key. Thus far, the alternative validation process operates in the same way as the principal validation process described hereinabove.

According to the alternative example embodiment, the validation package 96 for a given requesting node 24 and a corresponding validation request includes a list of validator entries identifying the validator nodes 16 assigned to the validation request, in which the list of validator entries are split into two sets of entries that each identify subsets of the assigned validator nodes 16 that perform slightly different tasks. A first set of validator entries correspond to a first subset of the validator nodes 16 of the assigned set and this first set includes validator identifiers identifying this first subset of validator nodes 16. The first set of validator entries also includes, for each identified validator node 16, a respective associated validator code. The contents of the first set of validator entries are readable by the requesting node 24 upon decryption by the requesting node 24, such as by using its unique appointment ID, its private key, or its request-specific key.

The validator codes contained in the first set of validator entries are encrypted asymmetrically in that each entry contains a different validator code but can be decrypted to a same resulting answer. This same resulting answer is an additional request-specific key. For a given validator code associated a given validator node 16, that validator node 16 possesses a corresponding decrypting code such that applying the decrypting code to the given validator code produces the additional request-specific key. The decryption by any validator node 16 identified in the first set of validator entries of its respective associated validator code produces this same additional request-specific key. A second set of validator entries corresponds to a second subset of the validator nodes 16 of the assigned set. The second set of validator entries include the identifiers identifying this second subset of validator nodes 16. The contents of the second set of validator entries are encrypted by an additional request-specific key. Therefore, the requesting node 24 must first obtain the additional request- specific key from one of the validator nodes 16 identified in the first set of validator entries before being able to access the second set of validator entries.

Furthermore, the validation package 96 also includes a nonce that is also encrypted by the additional request-specific key. This nonce is also known to the validator nodes 16 of the assigned set.

Referring now to Figure 5, therein illustrated is a schematic diagram of a list 160 of assigned validators included within a validation package 96 according to the alternative example embodiment. The list of assigned validators include the first set of validator entries 168, the second set of validator entries 176 and the nonce 184. The first set of validator entries 168 has two entries, each entry having the validator node identifier, the validator node address and the validator code (“ABCE” for validator 1 and “EFGFI” for validator 2). The second set of validator entries 176 are encrypted by the additional request-specific key and include two entries (identifying validator nodes 3 and 4). The nonce 184 is also encrypted with the additional request-specific key.

The requesting node 24 decrypts the first set of validation entries using its access element. It then transmits, to each of one or more of the validator nodes 16 identified in the first set of validation entries 168, the respective validator code for that validator node 16.

At each of at least one of the validator nodes 16 identified in the first set of validation entries 168, the validator node 16 receives its validator code from the requesting node 24 and decrypts it to produce the additional request-specific key. The validator node 16 may decrypt it using a decryption element shared between it and the trusted node 8. The decryption may require some computation at the validator node 16 to produce the additional request-specific key. The validator node 16 also logs the receipt of the validator code, such as timestamping this receipt. This validator code receipt timestamp can be included in the timestamped response package transmitted by the validator node 16 to the trusted node 8.

The requesting node 24 receives the additional request-specific key from any one of validator nodes and decrypts the second set of validator entries 176 and the nonce 184 using the additional request-specific key. At this moment, the requesting node 24 will have access to all of the information required to begin treatment of the security validation operations and to transmit proof of this treatment. It transmits the nonce 184 within a triggering message to each of the validator nodes 16 identified in both the first and second sets of validator entries 168, 176. The providing of the decrypted nonce 184 acts as proof that the requesting node 24 decrypted the second set of validator entries 176.

Each of the validator nodes 16 of the assigned set (including those identified in both first and second sets 168, 176) receives the triggering message and verifies that the correct nonce 184 is included in the triggering message. The validator node 16 logs the receipt of timestamp of the triggering message. This timestamp of the triggering message can represent a node-specific timestamp for the validator node 16 and the validator node 16 determines whether the validation response package is received in a timely manner from the requesting node 24 by using this timestamp as representing the start of the validation appointment time window. It will be understood that the timestamp of the triggering message can be slightly shifted temporally relative to the global start time of the validation appointment time window initially defined by the trusted node(s) 8.

Following the providing of the nonce 184 within the triggering messages transmitted to each of the validator nodes 16 identified in the first and second validator entries 168, 176, the requesting node 24 carries out treatment of the security validation operations and provides proof of the treatment in the validation response package 144 as described elsewhere herein.

Referring now to Figure 6, therein illustrated is a schematic diagram of the exchange of information between a requesting node and its associated validator nodes 16 according to the alternative example embodiment. Upon receiving the validation package 96, the requesting node 24 decrypts the identifiers of the first set of validator entries and transmits their respective validator codes (“ABC”, “DEF”) to the validator nodes identified in the first set (“Validator 1”, “Validator 2”). The validator nodes then use the validator codes to determine the additional request specific key 192, which is then transmitted back to the requesting node 24. The requesting node 24 uses the additional request-specific key 192 to decrypt the identities of the validator nodes (“Validator 3”, “Validator 4”) identified in the second set of validator entries 176. The requesting node 24 also decrypts the nonce 184. In a second step 200, the requesting node 24 transmits the triggering message having the nonce 184 to each of the validator nodes 16 of both the first and second sets 176, 184. Each of the validator nodes 16 logs a respective timestamp 208 of the receipt of the triggering message. The requesting node 24 continues by treating the validation security operations and transmits the proof of this treatment in the validation response packages in a third step 216. Each of the validator nodes 16 further logs another respective timestamp 224 of the receipt of the validation response package.

Referring now to Figure 7, therein illustrated is a schematic diagram of the contents of a validation package and of the validator nodes according to a further modification of the alternative example embodiment. This further modified example embodiment includes the use of an operations-specific code provided by the validator nodes identified in the second set of validator entries 176, in which the operations-specific code defines a customized subset of security validation operations to be treated for a given validation request. The operations-specific code further acts to temporally restrict knowledge of the exact security validations operations to be treated until after the triggering message (that includes the nonce 184) has been received by at least one validator node 16 of the second set of validator entries 176.

Continuing with Figure 7, and as already described with reference to Figure 5, the validation bundle 112 includes the first set of validator entries 168, the second set of validator entries 176 and the nonce 184. The example of Figure 7 illustrates this combination for two requesting nodes, which are identified as “Applicant ID 1” and “Applicant ID3”. The requesting node “Applicant ID 1” has as its first set of (open) validator entries 168 identifying validator nodes 16 having the identifiers “A” and “B”, as its second set of (secret) validator entries 176 identifying validator nodes 16 having the identifiers “C” and “D”, and its nonce 184 having the value “4”. The requesting node “Applicant ID 3” has as its first set of (open) validator entries 168 identifying validator nodes 16 having the identifiers “G” and Ή”, as its second set of (secret) validator entries 176 identifying validator nodes 16 having the identifiers “A”, “J”, and its nonce 184 having the value “9”.

Each validator node 16 has a respective set of decrypt codes 232 which are used to generate the additional request-specific key in response to receiving the validator code from the requesting node 24. For example, validator node “A” has a set of decrypt codes indicated as “[(1 ,X), ... ]”. This set of decrypt codes 232 is used by the validator node 16 when it acts as an open node for a given validation request, i.e. a validator node identified in a first set of entries 168 for a validation request.

According to the further modified example embodiment, the validator node 16 further has a set of secret codes 236 that are to be provided as an operations- specific code for a validation request. In the illustrated example, the validator node 16 having the identifier “Validator A” has a set of secret codes 236 indicated as “[(4,Y), (9,Z), ... ]”. The validator node 16 having the identifier “Validator J” has a set of secret codes 236 indicated as “[(9,V),...]”.

The validator node 16 is configured to only transmit one or more of its secret codes 236 only in response to receiving the correct nonce 184 from the requesting node 24. Upon receiving this nonce 184, the validator node 16 transmits one or more of its secret codes 236 to the requesting node 24. The secret code can be the one associated to the value of the received nonce 184. For example, where validator node “Validator J”, acting as a secret node, receives the nonce having the value “9” from requesting node “Applicant ID 3”, that validator node would then return secret code “V” that is associated to the secret code identified with “9”. This secret code 236 acts as the operations-specific code and defines a customized set of validation security operations for the given validation request. For example, the operations-specific code can define a customized selection of validation security operations (human-solvable puzzles and/or compute-intensive tasks) to be treated by the requesting node 24. Additionally, or alternatively, the operations-specific code(s) can act as inputs to the validation security operations. For example, the operations-specific code can be entered as input to one or more compute-intensive tasks, wherein the solution to these tasks is dependent on the inputted operations-specific code. Other permutations or variants are possible. For example, the initial validator code for a given validator node and its operations- specific code can be combined mathematically (ex: an XOR of the two codes) to generate another unique code for defining the customized set of security validation operations.

It will be appreciated that since the operations-specific code(s) is only available to the requesting node 24 after it has provided the nonce 184 to the validator node 168 identified in the second set of entries 168, the requesting node 24 is temporally restricted in when it can start its treatment of the validation security operations. This restricts the requesting node 24 from gaining a premature start in treating the validation security operations. Referring now to Figure 8, therein illustrated is a flowchart of the data flow between a requesting node 24 and its assigned open validator nodes (first set entries 168) and secret validator nodes (second set entries 176) according to the modified alternative example embodiment.

As described elsewhere herein, the requesting node 24 receives a validation package 96 (which may be part of a validation bundle 112) from the trusted node 8 (not shown in Figure 8).

At step 240, at substantially the start time of the validation appointment time window, the requesting node 24 receives the request specific key from the trusted node 8. At step 244, the requesting node 24 uses the request specific key to decrypt a portion of the list of validator nodes assigned to it as part of the validation request. As described elsewhere herein, only the open validator node entries (i.e. the first set of validator node entries) are accessible using the request-specific key.

At step 248, the requesting node 24 accesses the validator code for each of the validator nodes identified in the first set of validator entries 176 and transmits these codes along with its own identifier (ex: appointment identifier unique associated, on a network-wide basis, to the given validation request) within a trigger message.

At step 256, each of the open validator nodes 16 identified in the first set of validator entries 176 receives the requesting node identifier and the validator code from the requesting node 24. The open validator node 16 also determines that it has been assigned to perform validation for that requesting node 24. The validator node 16 will previously have been informed by the trusted node 8 to which validation requests the validation node 16 has been assigned, and whether it is to act as an open validator or a secret validator. Where the triggering message is sent from a requesting node 24 to which the validator node 16 was not assigned, the validator node 16 ignores the triggering message.

At step 264, upon confirming that the open validator node 16 is actually assigned to the requesting node 24, the validator node 16 decrypts the received validator code using its decrypt code 232 to generate the additional request- specific key. As described elsewhere herein, the validator codes are encrypted asymmetrically so that decrypting any of the validator codes leads to the same decrypted additional request-specific key. The additional request-specific key is transmitted by the open validator node 16 to the requesting node 24.

It will be understood that steps 256 and 264 are repeated at each open validator node 16 that is identified in the first set of validator entries 168 for the given requesting node 24.

At step 272, the requesting node uses the additional request-specific key to access further contents of the validation package. At step 280, the requesting node 24 accesses the second set of validator entries 176 and the nonce 184.

At step 288, the requesting node 24 transmits the nonce 184 to each of the validator nodes 16 associated to the requesting node 24 as part of the validation request. This can include both the validator nodes 16 identified in the first set 168 as well as the nodes 16 identified in the second set 176.

At step 296, each validator node 16 associated to the requesting node 24 receives the nonce 184. The receipt of the correct nonce indicates that the requesting node 24 has successfully used the additional request-specific key to access the secret content of the validation package, namely the second set of validator entries 176 and the nonce 184. At this step, each validator node 16 further records the timestamp of its receipt of the nonce 184. This timestamp marks the node-specific shifted start time of the validation appointment time window. As illustrated (marked as “puzzle time window”), this timestamp marks the beginning of the time window in which the requesting node 24 is to complete treatment of the security validation operations contained in the validation package 96.

Within step 296, each validator node 16 further identifies its respective operations-specific code for the given validation request. As illustrated in Figure 7, these codes are stored within a set of secret codes 240 at each validator node 16. The code chosen for the given validation request at each validator node 16 can be based on the value of the received nonce.

At step 304, each validator node 16 transmits its respective operations- specific code to the requesting node 24.

At step 312, the requesting node 24 receives the respective operations- specific code from each of the validator nodes 16. It will be appreciated that the operations specific code received from each validator node 16 may be different. As described elsewhere herein, the received operations specific code is used to generate a customized set of validation security operations for the given validation request. In this way, the requesting node 24 will only know the exact validation security operations that it must treat as part of the validation request upon receiving the operations-specific code (ex: which operations to treat and/or which inputs to use for the operations). Furthermore, it will be appreciated that because different operations-specific codes are transmitted from each of the validator nodes 16 of the assigned set, a customized set of security validation operations can be defined for each validator node 16. This further restricts the requesting node 24’s ability to predict ahead of time which operations it needs to treat.

The received operations-specific code received from each validator node 16 can be used to directly define the customized set of validation security operations.

Optionally, at step 320, the requesting node 24 can carry out a further modification of the operations-specific code. For example, and as illustrated, the operations-specific code can be mathematically combined with the initial validator code for the same validator node 16 to generate another unique code (“unique puzzle code”).

At step 328, the requesting node 24 treats the customized set of validation security operations. This can include the requesting node 24 treating each customized set of validation security operations generated from the different operations-specific code received from each of the validator nodes 16 of the assigned set.

At step 336, the requesting node 24 packages the results of the treatment of the validation security operations into validation response package(s). Where different operations-specific codes are received from each of the validator nodes 16, the requesting node 24 prepares a corresponding validation response package for each of these validator nodes 16. The validation response package(s) are transmitted by the requesting node 24 to each corresponding validator nodes 16 of the assigned set.

At step 344, each validator node 16 of the assigned set receives its corresponding validation response package from the requesting node 24. It further records the timestamp at which it receives the validation response package. It will be appreciated that the time difference between the package receipt timestamp and the nonce receipt timestamp indicates that amount of time that it took the requesting node 24 to complete treatment of the validation security operations, which further indicates whether this treatment was completed in a timely manner relative to the validation appointment time window.

At step 352, each validator node 16 of the assigned set prepares its timestamped response package that includes the validation response package it received from the requesting node 24 as well as the relevant timestamps (timestamp of receipt of the nonce 184, timestamp of receipt of validation response package, and, where available, timestamp of receipt of the validation code). As described elsewhere herein, according to some example embodiments, the validator node 16 can carry out the treatment of at least a portion of the security validation operations and then compare its solutions against the proof provided by the requesting node 24 within the received validation response package. This comparison generates a verification result that provides an indicator of whether the requesting node 24 correctly treated the security validation operations. Alternatively, the validator node 16 packages the proof of treatment of the received validation response package, as is, within the timestamped response package. Each validator node 16 further transmits its prepared timestamped response package to the trusted node(s) 8.

The trusted node 8 receives the timestamped response package from each of the validator nodes 16 assigned to the validation request and verifies whether, in the aggregate, they provide proof of treatment of the security validation operations and that the treatment was carried out in a timely manner relative to the validation appointment time window.

The use of operations-specific codes allows for generating customized sets of validation security operations that are treated by the requesting node 24 as part of the validation process. The trusted node 8 can be configured to store, in its validator nodes registry 48, the various decrypt codes 232and secret codes 236used by each of the validator nodes 16. Since the trusted node 8 initially generated the validation package that includes the list of assigned validator nodes 16, the value of the nonce 184, and the selection of validation security operations, it can use this information as well as the decrypt codes 232and secret codes 236of the validator nodes 16 to reconstruct the customized sets of security validation operations that were treated by the requesting node 24. For example, referring back to Figure 7, knowing that requesting node “Applicant ID 3” was assigned validator nodes “G”, “H”, “A”, and “J” and the nonce value “9” and that validator node “J” has secret code value “(9,V)”, the trusted node 8 can use this secret code as the operations-specific code to reconstruct the customized set of security validation operations for validator node “ J” and the requesting node 24. The trusted node 8 can also carry out treatment of these customized set of security validation operations. It then compares the results it obtained against the proof of treatment that it receives within the timestamped response packages from the validator node 16 to verify that the requesting node correctly treated the security validation operations. The aggregate of these comparison results across the timestamped response packages received from the validator nodes 16 of the assigned set is used to determine whether the requesting node 24 should be granted validated status. As described elsewhere herein, the trusted node(s) 8 also verify from the timestamps of the received timestamped response packages to determine whether the proof of treatment of the validation security operations was provided by the requesting node 24 to the validator nodes 16 of the assigned set in a timely manner relative to the validation appointment time window.

Referring now to Figure 9, therein illustrated is a schematic diagram of a list of assigned validator nodes included in a validation package 96 according to a simplified alternative example embodiment. According to this simplified version, the identifiers of all of the validator nodes 16 assigned to a given requesting node and its validation request are made available upon the requesting node 24 providing its access element (ex: request-specific key). It will be appreciated that in comparison to the examples of Figures 5 to 8, the validator nodes of the assigned set are not divided into two sets wherein it is necessary to contact the validator nodes 16 of the first set 168 in order to obtain access to the validator entries of the second set 176. Therefore, according to this simplified version, upon obtaining access to the identities of the validator nodes 16 and to the nonce 184, the requesting node 24 transmits the nonce 184 to each of the assigned validator nodes 16. Each validator node 16 records the timestamp of the receiving of the nonce 184, thereby indicating the start time of the shifted validation appointment time window. Each validator node 16 also returns its secret code 236, which is used by the requesting node as the operations-specific code to define the customized set of security validation operations that the requesting node 24 must perform as part of the validation status.

Referring now to Figure 10, therein illustrated is a flowchart of the data flow between a requesting node 24 and its assigned validator nodes 16 according to the simplified alternative example embodiment. It will be appreciated that the same steps as described herein with reference to Figure 8 are performed within the simplified alternative example embodiment, with the following changes. At step 244, the requesting node 24 uses the request specific key to decrypt the identifiers of the validator nodes 16 assigned to it. Steps 248, 256, 264, and 272 are not required for the requesting node 24 to decrypt the nonce 184. Instead, the decryption at step 244 allows obtaining the nonce 184 at step 280, which allows the requesting node 24 to proceed directly to step 288 of sending the nonce 184 to the validator nodes 16 of the assigned set. The remainder of the method can be carried out in substantially the same way as described with reference to Figure 8.

The systems and methods described herein according to various example embodiments allow for creating a validation appointment time window in which a requesting node is permitted to carry out operations as part of a validation process. Constraining the duration of the validation appointment time window allows for restricting the proliferation of user accounts by bad actors. A validation appointment time window can be applied to multiple validation requests at the same time.

Various example embodiments also provide for the verification within the validation process to be carried out by trust-less validator nodes 16, thereby achieving a substantially decentralized validation-enabled process. Only trusted nodes 8 need to be trusted to manage the validation process.

The systems and methods described herein can be used for validating a newly created user account, which initially has a non-validated status, as well for renewing the validation of user accounts that already have a validated status.

The systems and methods described herein relies on various cryptography measures to permit the validation to be carried out a public network, while ensuring that each node only accesses information relevant to that node. The cryptography measures are also used to ensure that the treatment of security validation operations occur only within the time-limited validation appointment time window.

According to various example embodiments, the frequency of the occurrence of the validation appointment time windows is restricted but multiple validation requests can be processed in parallel within any given validation appointment time window. Doing so, squeezes human or computer resources in time, which restricts proliferation of account creation by bad actors. For example, where a plurality of validation requests are scheduled for a single validation appointment time window and each validation requests includes security validation operations requiring human interaction to answer a human-solvable puzzle, a human user must be present for each of the validation request during that validation appointment time window. That is, a number of human user equal to the number of validation requests must be present (in parallel) during the validation appointment time window to successfully complete each of the validation request. This prevents a situation where a single human user can operate serially in time to create multiple accounts.

Similarly, wherein the plurality of validation requests are scheduled for a single validation appointment time window and each validation requests includes security validation operations involving computer-intensive tasks, the required computing resources must be contributed for each of the validation request during that validation appointment time window. That is, the computing resources must be multiplied (i.e. available in parallel) during the validation appointment time window to successfully complete each of the validation request. This prevents a situation where more limited computing resources are operated serially in time to solve compute-intensive tasks to create multiple accounts.

While the above description provides examples of the embodiments, it will be appreciated that some features and/or functions of the described embodiments are susceptible to modification without departing from the spirit and principles of operation of the described embodiments. Accordingly, what has been described above has been intended to be illustrative and non-limiting and it will be understood by persons skilled in the art that other variants and modifications may be made without departing from the scope of the invention as defined in the claims appended hereto.

Claims

1. A method for validating a requesting node on a network, the method comprising: at a trusted node, receiving, a validation request from the requesting node, the validation request including a set of one or more public keys associated to the requesting node; at the trusted node, in response to receiving the validation request, assigning a set of one or more validator nodes of the network to the validation request, defining a validation appointment time window for the validation request and generating a validation package for the validation request, the validation appointment time window having a start time and a window duration, and the validation package including identifiers of the one or more validator nodes of the assigned sets, one or more security validation operations and being encrypted by a request-specific key; at the trusted node, prior to the start of the validation appointment time window, making available the validation package over the network; at the trusted node, at substantially the start time of the validation appointment time window, making available the request-specific key to the requesting node; at each of the validator nodes of the assigned set, receiving a validation response package generated by the requesting node from treating the one or more security validation operations included in the validation package; at each of the validator nodes of the assigned set, generating a node specific timestamped response package based on the received validation response package and a timestamp of receipt of the validation response package, and transmitting the node-specific timestamped response package to the trusted node; at the trusted node, in response to receiving the node-specific timestamped response package from each of the validator nodes of the assigned set, determining a validation approval decision for the requesting node based on the node-specific timestamped response packages received from the validator nodes; and at the trusted node, if the validation approval decision is positive, registering the requesting node as having a validated status on the network and storing the public keys associated to the validated requesting node at the trusted node.

2. The method of claim 1 , further comprising: at each of the validator nodes of the assigned set, verifying that the validation response package contains proof of treatment of the security validation operations; wherein the node-specific timestamped response package is further prepared based on the verifying.

3. The method of claims 1 or 2, wherein the validation request is made in response to performing a rate-limiting operation by the requesting node, the validation request including proof of performance of the rate-limiting operation.

4. The method of any one of claims 1 to 3, wherein the request-specific key is a symmetrical encryption key.

5. The method of any one of claims 1 to 4, wherein assigning the set of one or more validator nodes of the network to the validation request comprises storing, at the trusted node, identifiers of the assigned set of one or more validator nodes in association with the validation request.

6. The method of any one of claims 1 to 5, wherein the validation package is made available without concurrently making available the request-specific key.

7. The method of any one of claims 1 to 6, wherein the validation package is made available before the making available of the request-specific key.

8. The method of claim 7, wherein the validation package is made available prior to the start time of the appointment time window by a security non-critical length of time.

9. The method of claims 7 or 8, wherein the request-specific key is made available immediately prior to the start time of the appointment time window by a security critical length of time.

10. The method of any one of claims 1 to 9, wherein the node-specific timestamped response package transmitted from each validator node of the assigned set is cryptographically signed by a private key specific to the given validator node and is verifiable by a corresponding public key stored by the trusted node.

11. The method of any one of claims 1 to 10, wherein determining a validation approval decision for the requesting node based on the node-specific timestamped response packages received from the validator nodes comprises determining whether the node-specific validation response packages are received in a timely manner relative to the validation appointment time window.

12. The method of any one of claims 1 to 11, wherein the validation status of the requesting node is determined according to a consensus determined from an aggregate of the timestamped response packages received from the validator nodes of the assigned set.

13. The method of any one of claims 1 to 12, further comprising, at the requesting node: receiving the validation package prior to the start of the appointment time window; receiving the request-specific key at approximately the start of the appointment time window; decrypting the security validation operations of the validation package using the request-specific key; treating the one or more security validation operations included in the decrypted validation package and generating the validation response package including proof of treatment of the one or more security validation operations; and transmitting the validation response package to each validator node of the assigned set associated to the validation request.

14. The method of any one of claims 1 to 13, wherein the validation package includes: a first set of validator entries being readable upon decrypting the package, the first set of validator entries corresponding to a first subset of the validator nodes of the assigned set, each entry having a validator identifier identifying a given validator node and a respective validator code, the validator code being transmitted by the trusted node along with assigning the given validator node to the validation request; a second set of validator entries being encrypted by an additional request-specific key provided by the trusted node to each of the validator nodes identified in the first set of validator entries in response to a validation request from the requesting node, the second set of validator entries corresponding to a second subset of the validator nodes of the assigned set; and a nonce also being encrypted by the additional request-specific key, the nonce also being transmitted by the trusted node to each validator node of the assigned set.

15. The method of claim 14, wherein decrypting the validation package comprises: decrypting the first set of validation entries; for each given validator node identified in the first set of validation entries, transmitting the respective validator code to the given validation node; receiving the additional request-specific key from the at least one validator node identified in the first set of validation entries; decrypting the second set of validator entries and the nonce using the second additional request-specific key; providing the nonce within a triggering message to each of the first and second subset of validator nodes, the receiving at each validator node triggering a respective node-specific start timestamp for the validator node.

16. The method of claim 15, wherein the performing the security validation operations and the generating the validation response package occur subsequently to transmitting the nonce.

17. The method of claims 15 or 16, wherein the requesting node further receives an operations-specific code from at least one validator node identified in the first set of validation entries, the operations-specific code defining a request-specific subset of the one or more security validation operations to be treated by the requesting node.

18. The method of any one of claims 1 to 17, further comprising: revoking the validated status for the requesting node after expiration of a predetermined validity time interval; transmitting a prompt to the validated node to renew the validated status, the renewal comprising carrying out the steps according to the methods of any one of claims 1 to 16.

19. The method of any one of claims 1 to 17, wherein the trusted node schedules a plurality of validation requests within a same validation appointment time window.

20. A network comprising network nodes configured to perform the method of any one of claims 1 to 19.

21. An access-controlled network system comprising: a trusted computing node configured for: receiving a validation request from a requesting node, the validation request including a set of one or more public keys associated to the requesting node; in response to receiving the validation request, assigning a set of one or more validator nodes of the network to the validation request, defining a validation appointment time window for the validation request and generating a validation package for the validation request, the validation appoint time window having a start time and a window duration, and the validation package including identifiers of the one or more validator nodes of the assigned sets, one or more security validation operations and being encrypted by a request-specific key; prior to the start of the validation appointment time window, making available the validation package over the network; at substantially the start time of the validation appointment time window, making available the request-specific key to the requesting node; receiving a node-specific timestamped response package from each of the validator nodes of the assigned set; in response to receiving the node-specific timestamped response package from each of the validator nodes of the assigned set, determining a validation approval decision for the requesting node based on the node-specific timestamped response packages received from the validator nodes; and if the validation approval decision is positive, registering the requesting node as having a validated status on the network and storing the public keys associated to the validated requesting node at the trusted node.

22. The access-controlled network system of claim 21 , further comprising: a plurality of validator computing nodes, the assigned set of validator nodes being selected from the plurality of validator computing nodes, each validator node being configured for: receiving the validator response package generated by the requesting node from treating the one or more security validator operations included in the validation package; generating a respective node-specific timestamped response packaged based on the received validation response package and a timestamp of receipt of the validation response package; and transmitting the respective node-specific timestamped response package to the trusted node.

23. The system of claim 22, wherein each validator node is further configured for verifying that the validation response package contains proof of treatment of the security validation operations; and wherein the respective node-specific timestamped response package is further prepared based on the verifying.

24. The system of any one of claims 21 to 23, wherein the validation request is made in response to performing a rate-limiting operation by the requesting node, the validation request including proof of performance of the rate-limiting operation.

25. The system of any one of claims 21 to 24, wherein the request-specific key is a symmetrical encryption key.

26. The system of any one of claims 21 to 25, wherein assigning the set of one or more validator nodes of the network to the validation request comprises storing, at the trusted node, the identifiers of the assigned set of one or more validator nodes in association with the validation request.

27. The system of any one of claims 21 to 26, wherein the validation package is made available without concurrently making available the request-specific key.

28. The system of any one of claims 21 to 27, wherein the validation package is made available before the making available of the request-specific key.

29. The system of claim 28, wherein the validation package is made available prior to the start time of the appointment time window by a security non-critical length of time.

30. The system of claims 28 or 29, wherein the request-specific key is made available immediately prior to the start time of the appointment time window by a security critical length of time.

31. The system of any one of claims 21 to 30, wherein the node-specific timestamped response packaged received from each validator node of the assigned set is cryptographically signed by a private key specific to the given validator node and verifiable by a corresponding public key stored by the trusted node.

32. The system of any one of claims 21 to 31 , wherein determining a validation approval decision for the requesting node based on the node-specific timestamped response packages received from the validator nodes comprises determining whether the node-specific validation response packages are received in a timely manner relative to the validation appointment time window.

33. The system of any one of claims 21 to 32, wherein the validation status of the requesting node is determined according to a consensus determined from an aggregate of the timestamped response packages received from the validator nodes of the assigned set.

34. The system of any one of claims 21 to 33, further comprising: the requesting node, being configured for: receiving the validation package prior to the start of the appointment time window; receiving the request-specific key at approximately the start of the appointment time window; decrypting the security validation operations of the validation package using the request-specific key; treating the one or more security validation operations included in the decrypted validation package and generating the validation response package including proof of treatment the one or more security validation operations; and transmitting the validation response package to each validator node of the assigned set associated to the validation request.

35. The system of any one of claims 21 to 34, wherein the validation package includes: a first set of validator entries being readable upon decrypting the package, the first set of validator entries corresponding to a first subset of the validator nodes of the assigned set, each entry having a validator identifier identifying a given validator node and a respective validator code, the validator code being transmitted by the trusted node along with assigning the given validator node to the validation request; a second set of validator entries being encrypted by an additional request-specific key provided by the trusted node to each of the validator nodes identified in the first set of validator entries in response to a validation request from the requesting node, the second set of validator entries corresponding to a second subset of the validator nodes of the assigned set; and a nonce also being encrypted by the additional request-specific key, the nonce also being transmitted by the trusted node to each validator node of the assigned set.

36. The system of claim 35, wherein decrypting the validation package comprises: decrypting the first set of validation entries; for each given validator node identified in the first set of validation entries, transmitting the respective validator code to the given validation node; receiving the additional request-specific key from the at least one validator node identified in the first set of validation entries; decrypting the second set of validator entries and the nonce using the second additional request-specific key; providing the nonce within a triggering message to each of the first and second subset of validator nodes, the receiving at each validator node triggering a respective node-specific start timestamp for the validator node.

37. The system of claim 36, wherein the performing the security validation operations and the generating the validation response package occur subsequently to transmitting the nonce.

38. The system of claims 36 or 37, wherein the requesting node further receives an operations-specific code from at least one validator node identified in the first set of validation entries, the operations-specific code defining a request-specific subset of the one or more security validation operations to be treated by the requesting node.

39. The system of any one of claims 21 to 38, wherein the trusted node is further configured for: revoking the validated status for the requesting node after expiration of a predetermined validity time interval; transmitting a prompt to the validated node to renew the validated status, the renewal comprising carrying out the steps according to the methods of any one of claims 21 to 37.

40. The system of any one of claims 21 to 39, wherein the trusted node schedules a plurality of validation requests within a same validation appointment time window.