AUTHENTICATION PROTOCOL USING A ONE-TIME PASSWORD

Abstract

Method of authenticating a client to a server, the client having beforehand registered on the server by storing therein a valid identifier (ID) and a hashed word (H.sub.0; H.sub.n) generated by applying a hash function to a disposable random variable (RAND.sub.0; RAND.sub.n; R.sub.n) possessed/known by both the client and the server and concatenated with a sequence (ISC.sub.0; ISC.sub.n) resulting from hashing the concatenation of a password (PWD) known from the client, said disposable random variable (RAND.sub.0; RAND.sub.n; R.sub.n) and an initialization sequence (ISC.sub.init) possessed by the client.

Claims

1. A method of authenticating a client to a server, the client having beforehand registered on the server by storing therein a valid identifier and a hashed word generated by applying a hash function to a disposable random variable possessed/known by both the client and the server and concatenated with a sequence resulting from hashing the concatenation of a password known from the client, said disposable random variable and an initialization sequence possessed by the client, comprising: a. the client requesting a connection session to the server by transmitting his/her/its identifier; b. the server checking the existence of the identifier and allowing the client to continue the authentication process; c. the client transmitting a backhash obtained by a modified hash function configured to conserve all the bits of the last internal state computed from the input data of said hash function; d. the server applying to the concatenation of the hashed word and the backhash an inverse hash function obtained by algebraically solving said hash function; e. the server comparing the result of the inversion to the random variable it possesses/knows; and f. if there is a match in the comparison of previous step e, authentication is successful for this connection session and the client is allowed to store on the server a new hashed word corresponding to a different random variable and a possibly different password for the next connection session; otherwise, authentication fails.

2. The method according to claim 1, wherein the hash function is a SHA-3 hash function.

3. The method according to claim 1, wherein the algebraic solving of the hash function is a SATisfiability solving.

4. The method according to claim 1, wherein in addition to being concatenated with the sequence, the disposable random variable is concatenated with a padding word in order to reach a predefined capacity of input data of the hash function.

5. The method according to claim 1, wherein in addition to being concatenated with the initialization sequence and the disposable random variable, the password is concatenated with a padding word in order to reach a predefined capacity of input data of the hash function.

6. The method according to claim 1, wherein the client and the server exchange the disposable random variable in plaintext.

7. The method according to claim 1, wherein a dedicated server generates the disposable random variable and transmits it to the client and the server.

8. The method according to claim 1, wherein the disposable random variable is generated by a specific device owned by both the client and the server.

9. The method according to claim 1, wherein the disposable random variable for a current connection is generated from the backhash of the immediately previous connection.

10. The method according to claim 1, wherein in addition to being concatenated with the sequence, the disposable random variable is concatenated with a short data, method further comprising: if there is a match in the comparison of step e, the client's identity and the short data are validated by the server which computes from the backhash the next disposable random variable and sends its hashed value to the client; the client computes the same way the next disposable random variable and compares its hashed value to the one received by the server; if there is a match in the comparison of previous step, the server is authenticated to the client, otherwise authentication fails; if the server's authentication is successful, the client can store on the server a new hashed word corresponding to the next disposable random variable and a possibly different password for the next connection session; the server hashes the concatenation of the next disposable random variable and the corresponding hashed word, and sends it to the client; the client performs the same hashing operation and compares the obtained result with that sent by the server; and if there is a match in the comparison of previous step, the client validates storing of the new hashed word by the server.

11. The method according to claim 1, wherein step d is performed on at least two servers, each of them partially carrying out algebraic solving of the hash function.

12. A computer program product comprising instructions that can be read by a client, these instructions controlling the client's authentication to a server on which is stored a valid identifier for the client and a hashed word generated by applying a hash function to a disposable random variable possessed/known by both the client and the server and concatenated with a sequence resulting from hashing the concatenation of a password known from the client, said disposable random variable and an initialization sequence possessed by the client, said instructions comprising: requesting a connection session to the server by transmitting the identifier and waiting for the server's acknowledgment; transmitting to the server a backhash obtained by a modified hash function configured to conserve all the bits of the last internal state computed from the input data of said hash function; and if authentication is allowed for this connection session, having the possibility to store on the server a new hashed word corresponding to a different random variable and a possibly different password for the next connection session.

13. A computer program product comprising instructions that can be read by a server, these instructions controlling a client's authentication to the server on which is stored a valid identifier for the client and a hashed word generated by applying a hash function to a disposable random variable possessed/known by both the client and the server and concatenated with a sequence resulting from hashing the concatenation of a password known from the client, said disposable random variable and an initialization sequence possessed by the client, said instructions comprising: allowing a connection session to the client if the right identifier is transmitted by the client after his/her/its connection request; waiting to receive from the client a backhash obtained by a modified hash function configured to conserve all the bits of the last internal state computed from the input data of said hash function; applying the concatenation of the hashed word and the backhash to an inverse hash function obtained by algebraically solving said hash function; comparing the result of the inversion to the random variable possessed/known by the server; and if comparison matches, allowing authentication for this connection session, and allowing to store a new hashed word corresponding to a different random variable for the next connection session; otherwise rejecting authentication.

14. A computer program product comprising instructions that can be read by both a client and a server, these instructions controlling the client's authentication to the server on which is stored a valid identifier and a hashed word generated by applying a hash function to a disposable random variable possessed/known by both the client and the server and concatenated with a sequence resulting from hashing the concatenation of a password known from the client, said disposable random variable and an initialization sequence possessed by the client, said instructions comprising: a. the client requesting a connection session to the server by transmitting his/her/its identifier; b. the server checking the existence of the identifier and allowing the client to continue the authentication process; c. the client transmitting to the server a backhash obtained by a modified hash function configured to conserve all the bits of the last internal state computed from the input data of said hash function; d. the server applying to the concatenation of the hashed word and the backhash an inverse hash function obtained by algebraically solving said hash function; e. the server comparing the result of the inversion to the random variable it possesses/knows; and f. if there is a match in the comparison of previous step e, authentication is successful for this connection session and the client is allowed to store on the server a new hashed word corresponding to a different random variable and a possibly different password for the next connection session; otherwise, authentication fails.

Description

DETAILED DESCRIPTION OF FIGURES

[0101] The invention will be better understood on reading the following detailed description of non-limiting exemplary embodiments thereof and on examining the appended drawings in which:

[0102] FIG. 1a, previously described, illustrates a general framework for the registration of a client on a server using a state-of-the-art method;

[0103] FIG. 1b, previously described, illustrates a general framework for the authentication of a client on a server using a state-of-the-art method;

[0104] FIG. 2, previously described, is a hashing process of an input sequence using the SHA-3 function;

[0105] FIG. 3, previously described, illustrates the generation of a security key using a modified SHA-3 function;

[0106] FIG. 4 schematically represents a registration of a client on a server, according to the invention;

[0107] FIG. 5 schematically illustrates an authentication of a client to a server according to the invention;

[0108] FIG. 6 schematically represents an embodiment of the invention;

[0109] FIGS. 7a and 7b schematically illustrate another embodiment of the invention;

[0110] FIG. 8 is an analogous view of FIG. 6 representing a third embodiment of the invention;

[0111] FIGS. 9 and 10 schematically illustrate a fourth embodiment of the 30 invention; and

[0112] FIGS. 11 and 12 schematically represents an example where several servers are used at the registration step and at the authentication step respectively.

[0113] FIG. 4 depicts the steps of a registration phase of a client on a server, necessary and prior to any connection to that server.

[0114] A secured connection is preferably established between the client and the server, as for example a SSL or TLS connection (Secure Sockets Layer or Transport Layer Security).

[0115] First and foremost, the client chooses an identifier ID whose availability is checked by the server. If the ID does not already exist in the server's database, registration is allowed. Then, the client gets a disposable random variable RAND.sub.0 that is also possessed by the server. The client concatenates this variable to a password PWD and an initialization sequence ISC.sub.init and hashes the result of the concatenation to obtain the sequence ISC.sub.0. This sequence is then concatenated to the random variable RAND.sub.0 and hashed by a modified hash function to give the hashed word H.sub.0 and the backhash FSC.sub.0. At the registration phase, only the hashed word H.sub.0 is sent to the server that stores it in a memory along with the associated identifier ID.

[0116] The memory may be an internal memory of the server or a remote one.

[0117] At the end of the registration phase, the client possesses RAND.sub.0 and ISC.sub.init and knows his/her/its identifier ID and password PWD, while the server possesses RAND.sub.0 , ID and H.sub.0 and knows nothing.

[0118] It is worth noting that, at the registration phase, both client and server do not consume huge computation resources, assuming that the hash function is a Keccak-type one.

[0119] In FIG. 5, steps of an authentication phase of a client to a server are schematically represented. For genericity purposes, the random variable noted RAND.sub.0 at registration phase on previous figure is noted RAND.sub.n in this figure.

[0120] First, the client requests a connection to the server by transmitting his/her/its identifier ID. The server then checks its existence to allow continuation of the authentication process, if appropriate.

[0121] Possessing RAND.sub.n and ISC.sub.init, and knowing his/her/its password PWD, the client is able to compute ISC.sub.n, like he/she did at registering. Also, as was done at registration phase, the client hashes the concatenation of ISC.sub.n and RAND.sub.n to obtain the couple (H.sub.n, FSC.sub.n).

[0122] The backhash information FSC.sub.n can be now transmitted to the server that possesses the hashed word H.sub.n, since the end of registration phase. By applying an inverse hash function to said couple, the server can reconstruct the random variable RAND.sub.n used by the client, and compare it to the one it possesses. The comparison should match if the client has entered the right password.

[0123] At this step, the server can get from the client a new proof of authentication associated with a new hashed word H.sub.n+1 computed from a new random variable RAND.sub.n+1 and possibly a new password PWD in case the client wants to change his/her/its password for the next connection session.

[0124] Such protocol offers the option of a one-time password. And as long as the password is entangled with a nonce random variable and a sequence ISC, weak passwords, as for example azerty, 12345 or 00000, may be authorized and used without any risks, provided the random variable is kept secret.

[0125] It should be noted that the most resource-consuming computation in the authentication method according to the invention is the algebraic solving of hash function. This computation is achieved by the server. So, implementation of such method on the client is rather cheap and simple, hence allowing to use the authentication process on low-power objects or sensors or connected objects e.g. cameras and remote actuators.

[0126] For instance, in a remote control of opening/turning on (a car, a door, etc.), the identifier ID is a unique number that is factory set, having 128 bits. The password, a value of 256 bits, may be either factory set, chosen or generated by the user or even derived from a biometric measure like a digital print, iris of the eye, etc.

[0127] In case the disposable random variable is generated from the backhash, the short data may be not used or may represent a control identifier (opening/closing, turning on/off, etc.).

[0128] In various sensors such as motion/smoke/flood detectors and measurement tools such as electric/water meters, the identifier ID and the password are also the same as for a remote control of opening/turning on, but in case the disposable random variable is generated from the backhash, the short data is directly measured by the sensor (intensity, meter value, etc.).

[0129] The authentication method according to the invention requires generating a different random variable whenever a registration or a connection is requested. This constraint mitigates replay attacks and also prevents an observer from the ability to determine whether the password has changed or not between two connections.

[0130] There are different ways allowing the client and the server to share possession of the disposable random variable.

[0131] Since it is not a confidential data, the random variable could be exchanged in plaintext between the client and the server, as shown in the embodiment of FIG. 6.

[0132] The client can transmit to the server the random variable along with the hashed word, and the server can transmit to the client the random variable with the identifier acknowledgment at the beginning of the authentication phase.

[0133] In the embodiment illustrated in FIGS. 7a and 7b, generation of the random variable is delegated to a dedicated server named Cryptonid server.

[0134] As shown in FIG. 7a, at registration phase, the client transmits his/her/its identifier and the server's identity to the Cryptonid server. Then, this one stores these pieces of information with a random variable that it generates and transmits to the client to enable him/her to compute the hashed word.

[0135] Later during the authentication phase, and just after receiving the backhash, the server transmits its identity and the client's identifier to the Cryptonid server as can be seen in FIG. 7b. The dedicated server then communicates the random variable.

[0136] The random variable may also be generated and shared via a specific device, as shown in the embodiment of FIG. 8. This device is in possession of both client and server and could be physical, for example a chip card like in SecurID technology, or software-based for instance, a smartphone or a computer application, etc.

[0137] FIG. 9 schematically depicts another embodiment of the invention where the disposable random variable is computed from the backhash of previous connection. This computation is done on both sides: the client's and the server's. Generating the random variable this way, independently of any external service/device, ensures that the same value of random variable cannot be reused and permits to authenticate the server to the client, as well.

[0138] FIG. 10 schematically represents a scenario of mutual authentication between the client and the server. After initiating a secure connection, the value of the random variable RAND.sub.n is communicated to both parties by a trusted entity. Still while having a secure connection, the client transmits to the server the hashed word H.sub.n, computed on the basis of the random variable RAND.sub.n and a short data d.sub.n that could be 256 bits long.

[0139] Then, not necessarily with a secure connection, the client sends the backhash F.sub.n to the server that will be able to inverse the hash function in order to check the correspondence of random variables. If the random variable R.sub.n resulting from the inversion is equal to the one stored, the server authenticates the client.

[0140] Thereafter, the server calculates the random variable R.sub.n+1 to be used for the next connection, on the basis of the backhash F.sub.n. Its hashed value h(R.sub.n+1) is then transmitted to the client.

[0141] From its side, the client also computes the same way the next random variable R.sub.n+1. If h(R.sub.n+1)=h(R.sub.n+1), the client validates the server's authentication and computes the next hashed word H.sub.n+1 using R.sub.n+1, d.sub.n+1 and possibly another password.

[0142] The server then stores the hashed word H.sub.n+1 received from the client, and calculates h(H.sub.n+1, R.sub.n+1) and sends it to the client, H.sub.n+1 being the hashed word it should **have recorded and that should correspond to .sub.n+1 received.

[0143] The client validates recording of last hashed word if h(H.sub.n+1, R.sub.n+1)=h(H.sub.n+1, R.sub.n+1). After that, next connection can be initiated; otherwise, if current connection is interrupted at any step, authentication process is reinitiated from the beginning.

[0144] These validation steps are useful to prevent Man in the Middle attacks.

[0145] FIGS. 11 and 12 represent an embodiment where several servers s.sub.0, . . . ,s.sub.xp are involved at the registration step and at the authentication step respectively.

[0146] At registration step, the first server s.sub.0 does not store the digest value h.sub.0 but only stores the backhash fsc.sub.0 resulting from the computation of H(H.sub.n, s.sub.0), s.sub.0 being a unique identifier of this server. The digest h.sub.0 is sent to the next server s.sub.x1. The destination server identifier is chosen using the digest value, so it is unpredictable without knowing all the information the first server knows about the user identity. Then, the next server proceeds the same way constructing a cycle that ends by sending the last hash and server identifier (h.sub.p, s.sub.xp) to the first server s.sub.0.

[0147] At authentication step, the first server s.sub.0 sends back the hash to the last server s.sub.xp which computes the previous hash and server identifier based on the backhash information fsc.sub.p it stored at registration step, and so on until the digest h.sub.0 returns back to the first server that can verify the user identity.

[0148] The invention is not limited to the examples that have just been described. In particular, features from the embodiments illustrated may be combined within embodiments that are not illustrated.

[0149] Other algebraic solving than SATisfiability solving may be used, as for example automated reasoning techniques, meta-heuristics, finite algebra solving techniques, or Grbner bases.

[0150] The method for authentication according to the invention and as defined above can be used in order to avoid the circulation of plaintext passwords on a network. The invention is not restricted to authentication on an information system but may be used in a lot of different applications, as for example in biometrics, internet of things, online transactions, locks, open/close control, turning on/off of devices, transmission of commands needing to be secured, etc., and wherever an authentication is required, demanding a high level of security.

[0151] The expression comprising a or including a must be understood as being synonymous with comprising at least one or including at least one, unless specified otherwise.