Patent Description:
A problem present in the state of the art is Client Identity verification. Client Identity verification can be done in the following ways: i) password-based authentication; ii) multi-factor authentication; iii) Certificate-based authentication; iv) Token-based authentication. Examples of such methodologies are disclosed in <CIT> and in <CIT>, and in references [<NUM>] and [<NUM>].

However, any of these methodologies presents problems. Notably, password-based authentication can be subject to phishing attacks, password guessing, etc. The multi-factor authentication is prone to situations when the devices are lost or unavailable to generate authentication codes. In its turn, certificate-based authentication is vulnerable to the theft of private keys. Finally, token-based authentication can be expensive when generating very secure tokens. If the token is leaked due to an unsecured connection, it can create several problems.

The present solution is intended to overcome such issues innovatively.

It is, therefore, an object of the present invention, a method, as defined in the appended claims, for authenticating a Client in a Client-Server Architecture. The method developed can be used by application(s) or device(s) to authenticate user(s), application(s) or device(s). These entities are further referred to as "Client" for the present application.

This method has three main components: Data, Model, and Policies. The data is made up of synthetic and real passwords of Clients. The Model is generated using the data and a computational modeling technique named Regulated Activation Network - RAN - [<NUM>]. Policies are created using the Model.

This new method for authenticating Clients in a Client-Server architecture has its significance in the domain of cybersecurity application-layer authentication. More particularly, the Client's input passcode is encoded using the RAN Model. Depending upon the Policy shared between the Client and Server, the different combinations of encoded passcodes are selected based on the number of layers and number of nodes in each layer in the Model generated. After every successful operation, a new Policy is generated and shared between the Client and the Server.

Because of these new policies, the Client inputs the same passcode for every authentication attempt, but the passcode communicated over the network is always different. This method is different from the prior art at least because it uses a Computational Model as part of the authentication procedure and uses Policies generated from the Model and the Client's passcode to generate the Client's encoded identity verification code. The advantages in respect of the prior art include random encoded passcode generation for the client's identity verification. This randomness also ensures that the generated encoded passcodes are never repeated in two successive authentication attempts.

For that purpose, in an advantageous configuration of the present invention method, it comprises a Model creation process, a Client creation process, and a Client authentication process.

The Model creation process is responsible for generating a Hierarchical model based on feeding a RAN computational model with a randomly generated N-dimensional input Dataset.

In its turn, the Client creation process generates a Client's Encoded Passcode Hierarchy by feeding the Hierarchical model with a Client's passcode. The Client's Encoded Passcode Hierarchy comprises a set of encoded passcodes representing encoded versions of the Client's passcode, and it is saved on the Server. The Client creation process is also responsible for generating a Policy for the Client's next authentication attempt and sharing it between the Client and the Server.

On the Client-side, the Client authentication process generates a Client's Encoded Passcode Hierarchy by feeding the Hierarchical Model with the Client's passcode. It also generates a Client's Encoded passcode using the Policy shared between the Client and the Server. Additionally, it authenticates the Client at the server-side if the Client's encoded passcode matches an expected encoded passcode generated at the server, using the saved Client's Encoded Passcode Hierarchy and the shared Policy. Finally, a new Policy is generated if the Client is successfully authenticated, which is then shared between the Client and the Server for the next Client's authentication attempt.

The more general and advantageous configurations of the present invention are described in the Summary of the invention. Such configurations are detailed below in accordance with other advantageous and/or preferred embodiments of implementation of the present invention.

The authentication method of the present invention comprises a Model creation process, a Client creation process, and a Client Authentication process. Additionally, the method can be implemented in a centralized manner such that the Model creation process, the generation of the Client's Encoded Passcode Hierarchy (<NUM>) on the Client creation process, and the generation of the Policy (<NUM>), (<NUM>) on both the Client creation process and Client authentication process are executed at the server's side. The Client (<NUM>) stores the Hierarchical Model (<NUM>) and the Policy (<NUM>), (<NUM>).

Alternatively, the method can be implemented in a decentralized manner wherein the Model creation process, the generation of the Client's Encoded Passcode Hierarchy (<NUM>), and the generation of the Policy (<NUM>), (<NUM>) on both the Client creation process and Client creation authentication process are executed at the Client's side. The Server (<NUM>) stores the Client's Encoded Passcode Hierarchy (<NUM>), the Policy (<NUM>), (<NUM>), and the respective Client's ID (<NUM>). Along with the strengths related to the randomness in encoded passcode generation, this decentralized manner empowers the Client (<NUM>) machine to have full control over the creation and store of the main authentication-related credentials (i.e., Model, Passcode, and Policies. ) and limits the role of servers (<NUM>) in saving the Clients (<NUM>) related credentials. In fact, the Model (<NUM>) generation and its update are independent of the Server (<NUM>), i.e., the Client (<NUM>) only notifies the Server (<NUM>) with the passcode hierarchy (<NUM>) if a new Model (<NUM>) is generated or a new Client (<NUM>) is created. Therefore, an attack on the server (<NUM>) does not compromise the Client's and authentication model related credentials.

In the centralized approach, the creation of Model (<NUM>) is executed on the server-side by the server administrator, selecting the amount of data to build the model. Additionally, the server administrator also sets the hyperparameters of the RAN's model (<NUM>) that further builds the Model (<NUM>). When Model (<NUM>) is built, it is made available to all the Clients (<NUM>). Alternatively, in the case of a decentralized approach, the creation of the Model (<NUM>) is a Client (<NUM>) operation, where the client-side application randomly generates a numerical dataset considering the client's passcode minimum and maximum values. The Client's application also arbitrarily selects the hyperparameters of the RAN's model, further building the model. When the model is built, it is saved on the client's device for further usage.

When an existing Client (<NUM>) logs in to the Server (<NUM>), it is authenticated by the old model (<NUM>) first, then its stored input passcode (<NUM>) is used to generate a new encoded passcode (<NUM>) set using the newly generated model (<NUM>). Therefore, new Models (<NUM>) can be arbitrarily generated, and the Client's model (<NUM>) will be updated automatically. These intermittently changed Models (<NUM>) drastically add to the variability induced by the random policy generation during the policy generation. This has been verified by regularly changing the Model (<NUM>) while testing the authentication and Client creation operations. In <FIG>, we can see three entities and their flow, which are described as follows:.

In a centralized approach, the Client (<NUM>) sends a Client creation request with the Client's ID (<NUM>), a passcode (<NUM>), and a token (<NUM>). Upon successful token (<NUM>) validation, the Client's passcode (<NUM>) is used as input to the RAN's model (<NUM>) to generate the encoded passcode (<NUM>). The encoded passcodes contained in the Client's encoded passcode hierarchy (<NUM>) are stored for the Client's authentication, and the Client's passcode (<NUM>) is stored to create newly encoded passcodes when the models (<NUM>) are changed. <FIG> illustrates the Client creation process. This process may be described as follows:.

Alternatively, in the case of a decentralized approach, the Client (<NUM>) sends a Client creation request with the Client's ID (<NUM>), a token (<NUM>), Encoded Passcode Hierarchy (<NUM>), and Policy (<NUM>). Upon successful token (<NUM>) validation, the Client (<NUM>) is acknowledged with a success message. <FIG> describes the Client creation process. This process may be described as follows:.

This process verifies the Client's identity. In this authentication process, three things are essential: first, the Client's input passcode (<NUM>); second, the Model (<NUM>) shared between Client (<NUM>) and Server (<NUM>); and third, the Policy (<NUM>) shared between Client (<NUM>) and Server (<NUM>). When a Client (<NUM>) attempts to authenticate, it's passcode (<NUM>) is passed through the Model (<NUM>) to produce the Client's Encoded Passcode Hierarchy (<NUM>). Further, an Encoded Passcode (<NUM>) is created using the Policy (<NUM>) and the Client's Encoded Passcode Hierarchy (<NUM>). This Encoded Passcode (<NUM>) is sent to the Server (<NUM>). In the case of a decentralized approach, a new Policy (<NUM>) for the next authentication is also sent to the Server (<NUM>).

To verify the Client (<NUM>), the Server (<NUM>) loads the Client's Encoded Passcode Hierarchy (<NUM>) saved on the Server (<NUM>) and the Policy (<NUM>) that was shared between the Client (<NUM>) and the Server (<NUM>). If both the encoded passcodes match, the Client (<NUM>) is acknowledged with an authentication success message. In the case of a centralized approach, a new Policy (<NUM>) is also sent to the Client (<NUM>) to be used in the next authentication approach. In the case of a decentralized approach, the current Policy (<NUM>) at the server (<NUM>) is replaced by the new Policy (<NUM>) sent by the Client (<NUM>). If both the encoded passcodes do not match, the Client (<NUM>) is acknowledged with an authentication failure message.

The method developed ensures that in two consecutive authentication attempts by a Client (<NUM>), the Encoded Passcode (<NUM>) is never repeated, which is confirmed by keeping a log of Policies (<NUM>) used in the Authentication operations. Table <NUM> lists the Iteration Log obtained that proves it. Validation was performed from <NUM> authentication operations until <NUM> million authentication attempts in different experiment sets. It can be seen that until <NUM>,<NUM> authentication operations, no two consecutive Policies (<NUM>) were repeated. When the authentication iteration grew to <NUM>,<NUM> attempts, it can be observed that Policies (<NUM>) have repeated, but two Policies (<NUM>) are never observed one after the other in two consecutive authentication attempts.

<FIG> shows the entire Client authentication process in case of a centralized approach. The process may be as follows:.

<FIG> also shows the entire authentication process in the case of a decentralized approach. The Process may be as follows:.

The robustness of the developed authentication method, with respect to randomness, is achieved through the Policies (<NUM>). The Policy (<NUM>) itself is derived from the architecture of the Model (<NUM>) generated using RAN (<NUM>). A Policy (<NUM>) may be made using the following steps:.

The Client's Encoded Passcode Hierarchy (<NUM>) can be generated by propagating the Client's input passcode (<NUM>) to the generated RAN's model (<NUM>). This process encodes the Client's input passcode (<NUM>) into varied sizes based on the size of the layers of the Model (<NUM>). For example, in <FIG> the input passcode (<NUM>) is [<NUM>, <NUM>, <NUM>, <NUM>]. At the input layer, L. <NUM>, the passcode (<NUM>) is normalized between <NUM> and <NUM> (by dividing them by <NUM>), but the size of the passcode (<NUM>) remains the same. In Layer L. <NUM> dimension of input is reduced to <NUM> with encoded values [<NUM>, <NUM>]. At Layer L. <NUM> the dimension was expanded to <NUM> with encoded values [<NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>] and the last layer L. <NUM> the dimension is again reduced to size <NUM> with encoded values [<NUM>, <NUM>, <NUM>]. These encoded input passcode at different layers are seen as a hierarchy of the Client's input passcode (<NUM>). Note, the Encoded Passcode Hierarchy (<NUM>) of the Client (<NUM>) does not include the input Layer L. <NUM> because it can reveal the Client's input passcode (<NUM>). Therefore, the Encoded Passcode Hierarchy (<NUM>) of the Client (<NUM>) consists of encoded passcodes from Layer L. <NUM> onwards until the highest layer (L. β-<NUM>) in the Model's architecture. At the Server (<NUM>), this Encoded Passcode Hierarchy (<NUM>) exists in a persistent form, i.e., it is saved with the Client's profile in place of the Client's Passcode. This hierarchy (<NUM>) is generated on the Client's side whenever the Client (<NUM>) attempts to perform the authentication. In the case of a decentralized approach, the Encoded Passcode Hierarchy (<NUM>) is controlled by the Client (<NUM>), i.e., whenever the Client (<NUM>) wants, can replace the current Encoded Passcode Hierarchy (<NUM>) with a new one.

The Encoded Passcode (<NUM>) is the actual passcode that is sent by the Client (<NUM>) via the internet (for example) to the Server (<NUM>) for authentication. The Encoded Passcode generation is depicted in <FIG>. This Encoded passcode (<NUM>) is generated twice in one authentication attempt:.

As will be clear to one skilled in the art, the present invention should not be limited to the embodiments described herein, and a number of changes are possible which remain within the scope of the present invention.

Claim 1:
Method for authenticating a Client in a Client-Server architecture, the method comprising a Model creation process, a Client creation process, and a Client authentication process; wherein,
the Model creation process generates:
(i) at the Client-side or at the Server-side, a Hierarchical model (<NUM>), shared between the Client and the Server, based on feeding a Regulated Activation Network computational model (<NUM>) with a randomly generated N-dimensional input Dataset (<NUM>), said Hierarchical model (<NUM>) comprised by a plurality of layers;
the Client creation process generates:
(i) at the Client-side or at the Server-side, a first Client's Encoded Passcode Hierarchy (<NUM>) by feeding the Hierarchical model (<NUM>) with a Client's passcode (<NUM>); the Client's Encoded Passcode Hierarchy (<NUM>) being saved on the Server (<NUM>) and comprises a set of encoded passcodes representing encoded versions of the Client's passcode (<NUM>); the Client's Encoded Passcode Hierarchy (<NUM>) being formed by layers of the Hierarchical model (<NUM>), wherein each of said layers, except input layer, stores an encoded version from said encoded versions of the Client's passcode (<NUM>);
(ii) at the Client-side or at the Server-side, a Policy (<NUM>) for the Client's next authentication attempt, which is shared between the Client (<NUM>) and the Server (<NUM>); and
the Client authentication process:
(i) generates, at the Client-side, a second Client's Encoded Passcode Hierarchy (<NUM>) by feeding the Hierarchical Model (<NUM>) with the Client's passcode (<NUM>) and a Client's Encoded passcode (<NUM>) is created using the Client's Encoded Passcode Hierarchy (<NUM>) and the Policy (<NUM>) shared between the Client (<NUM>) and the Server (<NUM>);
(ii) authenticates the Client (<NUM>) at the server-side if the Client's encoded passcode (<NUM>), received from the Client, matches an expected encoded passcode generated at the server (<NUM>) using the saved first Client's Encoded Passcode Hierarchy (<NUM>) and the shared Policy (<NUM>);
(iii) generates, at the Client-side or at the Server-side, a new Policy (<NUM>) if the Client (<NUM>) is successfully authenticated, which is shared between the Client (<NUM>) and the Server (<NUM>) for the next Client's authentication attempt.