FR2913551A1 - User authenticating method for use in Internet network, involves authenticating authentication server by token and vice versa for each of web pages requested by user, by executing control script e.g. java script, in computer - Google Patents

Abstract

The method involves authenticating an authentication server (105) by token and vice versa for each of web pages (106) requested by user (100), by executing a control script (107) e.g. java script, in a computer (102), where an authentication system is connected to the computer for authenticating the user after the authentication server is connected to an Internet network (101). The control script is either recorded in the computer or included in a web page transmitted by a web server (103), where the script is recorded in the computer when the computer receives the web page.

Description

TECHNICAL FIELD The invention relates to securing transactions

  on the Internet between a user and the site to which he is referenced and on which he wishes to connect, and concerns in particular a method of mutual authentication and recurring on the Internet between the user and the site.

  STATE OF THE ART When a user consults a website, authentication is a major issue, in order to fight against identity theft problems, and site presentation falsified by hackers for the purpose they recover. confidential data. The authentication of the user, on a site to which it is referenced, that is to say with which it was the subject of a prior registration, is conventionally performed by entering a user identifier and a password. This technique is not very secure because spyware exist to retrieve the information entered.

  Another technique is to use an authentication device such as a USB key as described in patent application US 2001 045451, or a smart card and its reader, capable of generating dynamic passwords for single use. An authentication server, or an authentication module on the visited site, is able to generate the same password, and therefore to verify the validity of that generated by the authentication device. This technique is better than the previous one, since the password varies over time, but it only protects the connection and not all the pages visited. An attacker can be inserted after the connection to recover confidential data, or go to the site without going through the initial connection (by recovering an existing session for example).

  User authentication of the site is a more recent problem. The systems in place concern either the display on each web page of a sentence or a picture defined by the user during his registration as described in US patent application 2006 230435, or lists of valid sites. that the user can set in his browser. The first technique is insufficient, because any content of a web page can be diverted and reused by a hacker, and the second is impractical and exposed to browser vulnerabilities. In addition, authentication methods between a client and a server are numerous. There may be mentioned, among others documents US 2004 205344 which proposes a method based on non-dynamic keys; US 2004 230800 which proposes a method based on challenge data; US 2004 255037 which proposes a method based on the exchange of non-dynamic certificates or JP 2004 023662 and JP 11.340.969 which describe a method based on a static key and random numbers. But none of the above documents describes a complete system for mutual and recurrent authentication, that is iteratively performed throughout the site visit.

  SUMMARY OF THE INVENTION This is why the object of the invention is to provide an authentication method between a user of the Internet network and the site on which he connects, which is mutual and recurrent and which is based on keys. dynamic and a signature of these keys. The invention relates to a method for authenticating a referenced user to an organization and whose computer is connected to the Internet. The user wishes to have access to at least one web page provided by a web server of the organization so as to perform the visualization of said web page. An authentication apparatus, connected to the user's computer, is adapted to authenticate the user to an authentication server connected to the Internet. The method is characterized in that for each of the web pages requested by the user, it consists in having the authentication server authenticated by the token and vice versa.

  According to an essential characteristic of the invention, authentication of the authentication server by the token and vice versa is performed by the execution of a control script recorded in the computer. The control script is either stored in the computer prior to the implementation of the method, or included in each of the web pages transmitted by the web server, or included in the first web page transmitted by the web server and registered in the web server. computer when it receives the web page, is integrated into the web browser. More specifically, the method according to the invention consists, for any request for a web page, to: - request the identifier to the token, - transmit a request for a session request to the authentication server, - transmit the request session returned by the authentication server to the token, -check the validity of the session request by the token, - transmit the session response of said token to the authentication server, -check by the authentication server the response of session of the token, send to the web server the result of the authentication, and -recommencer the preceding steps when, after a duration of predetermined value, the visualization of the web page is not completed.

  BRIEF DESCRIPTION OF THE DRAWINGS The objects, objects and features of the invention will appear more clearly on reading the following description with reference to the drawings, in which: FIG. 1 is a block diagram showing the main components of the invention, in which are implemented the method for mutual authentication between the user and the server of the visited website, Figure 2 is a diagram showing the sequencing of the messages exchanged between the authentication server and the token, as well as the main data managed by these two components, Figure 3 is a diagram showing the main sequencing of the messages exchanged between the different components to achieve the method according to the invention, Figure 4 is a block diagram showing the deployment of the invention when there has two web servers attached to a single authentication server, Figure 5 is a block diagram representing the deployment of the invention when there are two web servers each attached to a specific authentication server, Figure 6 is a diagram showing the sequencing of the messages exchanged between the different components to achieve the method according to the invention. invention in a simplified mode, where the web server and the authentication server are grouped together.

  DETAILED DESCRIPTION OF THE INVENTION The method of the invention is implemented in a system illustrated by the block diagram of FIG. 1. In such a system, a user 100 who is connected to the Internet network 101 by means of a computer 102 wishes to have access to a web server 103 connected to the Internet to obtain one or more web pages. Conventionally, the authentication of the user is performed using an authentication device 104 (called token thereafter) connected to the computer 102 and an authentication server 105 connected to the Internet network, and / or by the exchange of an identifier and a password. Note that the authentication device available to the user because the latter is referenced to the site, is a device that connects to the user's computer by one of its plugs. interface (commonly the USB socket). But unlike current systems, the authentication is performed via the web page 106 received from the web server 103. The web page is constituted on the one hand of all the information presented to the user, and specific to the visited web site, and secondly a control script 107. The control script 107 is a software module that plays a central element in the authentication. It is through it that the token 104 is linked via its interface software (preferably an ActiveX control), the authentication server 105 and the web server 103. In the preferred embodiment, the technologies used to implement the control script are JavaScript and AJAX. JavaScript is a web client-side programming language, and AJAX is a set of technologies for performing transparent queries to a web server. The use of another similar technology would not change the principle of the present invention.

  An important feature of the invention lies in the fact that the authentication between the authentication server and the token is based on: a pair of cryptographic keys by token and by web server, and generated by the authentication server, also called session keys. These keys make it possible to encrypt the messages exchanged between the token and the authentication server.

  The use of a key pair ensures that there is always a common key between the authentication server and the token, even when the updating of these keys is not done correctly, for example following a communication problem, - a request identifier generated by the web server. This is a dynamic element that can not reuse messages already exchanged between the web server and the authentication server on the one hand, and the authentication server and the token on the other hand. Each new identifier must be a unique value for a given token (it can be a counter, or the date and time indicating an absolute date with respect to a repository), - signatures of requests and responses between the web server and the authentication server on the one hand, and the authentication server and the token on the other hand. These signatures make it possible to certify the origin of requests and responses. A token, which makes it possible to authenticate one or more web servers, permanently contains the following data, summarized in FIG. 2: a unique identifier, among all the tokens, data relating to each web server it can identify, including in particular: -the unique identifier of the web server, among the set of web servers, -the identifier of the last request of the web server, -a pair of dynamic cryptographic keys: the current key and the previous key . This data is stored in the token in a nonvolatile manner, by a device such as a Flash memory.

  The authentication server, the main data of which is summarized in FIG. 2, continuously contains a recording by web server and by token between which there is possible mutual authentication, and comprising: the unique identifier of the token, among the set of tokens, - the unique identifier of the web server, among all the web servers, which can identify the token, - the identifier of the last request of the web server, - a pair of dynamic cryptographic keys: the current key and the new key. This data is stored in the authentication server in non-volatile form by a device such as a database.

  Initially, the values of the keys are as follows: the current key of the authentication server and the current key of the token are identical, the old key of the token is identical to its current key, the new key of the server of authentication is empty (invalid).

  In the invention, the cryptographic algorithms used are of little importance. For encryption, they may be symmetric (DES, EDES, AES or other) or asymmetric (RSA, DSA, or other) keys, and for algorithm signatures such as MD5, SHA-1, or others. The invention uses some of these algorithms, but the implementation described here is specific. The embodiment uses a symmetric AES algorithm for encryption, which is sufficient knowing that the security is based on the dynamism of the keys and the uniqueness of these keys between the tokens, and uses to sign the messages exchanged the MD5 algorithm . The method according to the invention is now described with reference to FIG. 3. When the user connects to an Internet site 301, a first authentication page can be presented to him by requesting his username and password. This first step is not essential, but may allow a first level of authentication. In the latter case, and if the user is not recognized by the web server (unknown identifier or bad password), the connection is not possible. If the user is recognized, or if the previous step does not exist, the web server presents him with a first web page asking him to connect his token to his computer 302. This page contains the following dynamic authentication information: - the identifier of the web server, - a unique identifier of the request, - a signature of the authentication request.

  The signature makes it possible to certify that the request actually comes from the web server, and can be calculated as follows: signature = function (web server identifier, request identifier, password between the web server and the authentication server). When the user has connected his token and validated the request, the control script 15 transmits an identifier request to the token 303. On this request, the token simply returns its unique identifier 304, making it possible to recognize it among the set of chips. The control script then requests the authentication server to request a session request 305. This is an HTTP or HTTPS request containing the following information: the identifier of the web server, contained in the web page, - a unique request identifier, contained in the web page, - the signature of the request of the web server, contained in the web page, - the identifier of the token, read previously. On a request for a session request 305, the authentication server performs the following processes, using its data base: - it verifies the existence of the token, by its identifier, - it verifies the existence of the web server, by its identifier, - it verifies that this web server can use this token, 30 - it verifies that the request identifier of the web server has not already been used (for example by verifying that it is greater than the last identifier request of this web server for this token), - it verifies the signature of the request of the web server. This signature certifies that only this web server could issue the request. To do this, he himself calculates this signature and compares it with the signature received. If one of the previous checks is invalid, the authentication server returns a response 306 indicating an error. This negative result is then sent by the control script to the web server as the result of authentication 313. If all the previous checks are valid, the authentication server creates an HTTP session to keep the received data up to token session verification request 310. It creates a new session key if the current value of this key is empty (invalid), and updates it in its database. Otherwise, it uses the current value of this key. It returns a response 306 containing the following session request data: the identifier of the web server having requested the authentication, the authentication request identifier of the web server, the new session key, the signature of this session request, which can be calculated in the following way: signature = function (web server identifier, request identifier, token identifier, current key, new key), all this data, excluding the identifier of the web server, are encrypted using the current key. Keys manipulated are those associated with the couple (token, web server). On receipt of the response 306, the control script performs a session request to the token 307 with the data of this response 306. On a session request 307, the token checks the session request and performs the following processes 308: -il search the web server identifier among those it owns. If it does not find this identifier, it returns an error in its response 309. Otherwise, it subsequently uses the data associated with this web server, it decrypts the other data of the message with the current key, calculates the signature of the same as the authentication server, and compares the calculated signature with that received in the message. If the two signatures are different, it repeats the operation using the old key. If the two signatures are again different, it returns an error in its response 309, - it verifies that the request identifier of the web server has not already been able to be used (for example by checking that it is greater than the last request identifier of this web server that he has stored). If it is not, it returns an error in its response 309.

  If all checks are valid, the token correctly authenticated the authentication server. It transfers the current key in the previous key, then the new key contained in the session request message, and decrypted successfully, in the current key, these keys being those associated with the web server that requested the authentication. It returns a session response 309 to the control script, this response being signed in the same way as in the session request 307, and encrypted with the new current key. The session of the token becomes valid again for a fixed duration (i.e. thirty seconds), this duration being managed by a timer within the token. In the preferred embodiment, the token manages a green LED to inform the user of the authentication of the visited site. The token informs the user of the validity of the session by turning on the green LED. When the session becomes invalid, or if there is no session, the green LED is off. Upon receipt of the session response 309, the control script sends the authentication server a session verification request 310. This is an HTTP or HTTPS request containing the session response data of the token 309. On a session verification request 310, the authentication server retrieves the data associated with the request, thanks to the HTTP session that it has created during the processing of the request 305. It verifies the session response of the token, and performs the following 311 processing, using its database, and the associated web server and token data: - it verifies that the token signature is correct, calculating itself that signature, and then encrypting it with the new key, and comparing this encrypted signature with that returned by the token, - if the signatures are identical, the token has been correctly authenticated. The authentication server 30 transfers the new key into the current key, and invalidates the new key (its value becomes empty). If one of the checks is not valid, the authentication server returns an authentication result indicating an error 312.

  If all checks are valid, the authentication server returns an authentication result indicating a correct result. This correct result is signed, in order to certify the positive responses of the authentication server to the web server. The signature can be calculated in the following way: signature = function (web server identifier, token identifier, request identifier, authentication server response code, password between the web server and the authentication server). When the authentication is complete, following an error or a successful authentication, the control script sends an authentication result request 313 to the web server via an HTTP or HTTPS request. This request contains the following information: - the request identifier of the web server, which was in the web page, - the identifier of the token, - the result code of the authentication, - the signature of this result code, when the result is positive.

  When the web server receives an authentication result request 313, following the initial connection of the user, it performs the following actions, using its database: if the authentication result is positive, it checks: - that the token is that of the user who has identified himself, by comparing the identifier of the token with the one owned by the user. If there is no step of authentication of the previous user by user ID and password, this check does not take place, - that the signature of the authentication server authentication result is correct. To do this, it calculates itself this signature in the same way as the authentication server, and compares the two signatures that must be identical, - that the request identifier corresponds to the identifier of the last request of authentication performed by the web server. If all the checks are valid, the web server connects the user in the confidential space and sends him a page in this space 314.

  If one of the checks is not valid, or if the authentication result is negative, the web server disconnects the user and sends back a page indicating an error 314.

  When the user is connected in the confidential space, after a first successful authentication of his token, the web server presents him a web page of the confidential space 314, which contains the following dynamic authentication information: - the identifier the web server, - a unique request identifier, - a signature of the authentication request, - the URL that the control script must call to send the next recurring authentication result. When the loading of the web page in the user's browser is completed 315, the authentication procedure between the token and the authentication server previously described between steps 303 and 312 is automatically initiated, thanks to a standard HTML mechanism (window.onload), and seamlessly for the user. This procedure extends from the request for identification of the token 316, to the return of authentication result of the authentication server 320.

  When the response 320 of the authentication server is received, or following an error in the authentication steps, an HTTP or HTTPS request is sent to the web server 321. The URL of this request has been retained in the control script thanks to the message 314. The same parameters as 313 are added to this URL, namely: the request identifier of the web server, which was in the web page, the identifier of the token, the result code of the authentication, - the signature of this result code, when the result is positive. Unlike step 313, which corresponds to a request for a new web page to the web server, for example following the support of a button of the user, the result 321 does not require a new page from the web server, which would be visible to the user. This is a request sent transparently to the web server, which is not intended to update the current web page, but to report the result of authentication. When the web server receives an authentication result request 321 following a transparent authentication request, it performs the same verification actions after receiving an authentication result 313. It also verifies that the user is already connected. If all the checks are valid, the web server returns a response 322 to the request 321 containing: the type of action to be taken, which is here normally a new authentication request, the identifier of the web server, a unique identifier of the request, - a signature of the authentication request, - the activation delay of the next authentication request in the control script. If one of the checks is not valid, or if the authentication result is negative, the web server in principle closes the user's HTTP session, and returns a response 322 to the request 321 containing: the action type to undertake, which is specific to the web server, any additional parameters, specific to the web server. When the control script receives a response 322, it retrieves the action to be taken in the response.

  If the action to be taken is an authentication request, the control script retrieves the parameters of the action, and starts a timer 323 whose duration is indicated by one of the parameters of the request 322. At the end of this delay, a new identification starts 324. The procedure is iterative, as long as the authentication is successful (steps 316 to 323).

  The web server can also, in case of authentication error, request a new authentication. It is only after several consecutive failures that the action will be to disconnect the user. If the action to be taken at 322 is not an authentication request, the control script retrieves the parameters of the action, and calls a default procedure, which must be redefined by the web server in its web page. In this procedure, which deals in principle with an authentication error, the web page invokes a new web page that normally indicates to the user an authentication error. For the following pages, the authentication procedure between the token and the authentication server described above (steps 303 to 312) is started automatically. When the authentication result response of step 312 is received from the authentication server, the request for the web page is sent to the web server with the authentication result data, as in step 313. such a web page request, the web server verifies the result of the authentication before serving the web page. If the result is correct, it presents the new requested page containing the new dynamic authentication information as in step 314, otherwise it presents an error page. The procedure then continues, as explained from step 314. When, after a delay defined by the web server, the latter has not received an authentication result, the web server closes the user's HTTP session, and presents him with a web page indicating an authentication error. Finally, and to explicitly close a session at the token level, a request for logoff is available. This request is sent by the control script to the token when the user disconnects from the visited website.

  The deployment of the invention can be realized in several ways. In a first embodiment shown in FIG. 4, an authentication server 105 is shared by several web servers 401 and 402. In a second embodiment shown in FIG. 5, an authentication server is dedicated to each server. web. The authentication server 503 is dedicated to the web server 501, and the authentication server 504 is dedicated to the server 502. Note that, when an authentication server is dedicated to each web server, the authentication server can make integral part of the web server, in the form of a software module, and not as a specific server; in this situation, the web server and the authentication server are merged. In this case, a number of simplifications can be made, and are detailed below. These modifications concern the data kept in the token and the authentication server on the one hand, the messages exchanged and their content on the other hand. The token may be associated with only one web server; the identifier of the web server therefore no longer has any reason to be managed and transmitted. Similarly, there is no reason either to authenticate the web server to the authentication server. The token then retains only the following data: - its identifier, - the identifier of the last request, the current key, - the old key. The authentication server keeps a token record containing the following data: the identifier of the token, the identifier of the last request, the current key, the new key. The messages transmitted between the web server, the control script and the token are shown in FIG. 6. This figure is a simplification of FIG. 3; the main differences are the following: the session request request 305 is directly addressed to the web server, the session verification request 310 and the authentication result request 313 are grouped into a single request 310. Schematically on the Figure 6, the return of the authentication result 312 and the authentication result request 313 are deleted.

Claims (15)

  1. Method of authenticating a user referenced to an organization and whose computer (102) is connected to the Internet network (101) and wishing to have access to at least one web page provided by a web server (103) said organization for performing the visualization of said web page, said computer to which is connected an authentication apparatus (104) being adapted to authenticate said user to an authentication server (105) connected to the Internet network; said method being characterized in that for each of the web pages requested by the user, it consists in having said authentication server authenticated by said token and vice versa.   The method of claim 1, wherein authentication of said authentication server by said token and vice versa is performed by execution of a control script in said computer.   3. Method according to claim 2, wherein said control script is either recorded in the computer prior to the implementation of the method, or included in each of the web pages transmitted by the web server, or included in the first page. web transmitted 20 by the web server and saved in the computer when it receives the web page, is integrated into the web browser.   4. Method according to one of claims 1 to 3, wherein said authentication server is separate from said web server, said method comprising the steps of, for any request for a web page, - request the identifier at token (303), - transmitting a session request request containing the identifier of said token to said authentication server (305), - transmitting the session request returned by said authentication server to said token 30 (307), - checking by said token the validity of said session request (308), - transmitting the session response of said token by a session verification request to said authentication server (310), - verifying by said authentication server the session response of said token, in order to authenticate it (311), - send the result of the authentication by a request to said web server (313), and - repeat the preceding steps when, at the end of a predetermined value duration the display of the said web page is not over.   5. Method according to one of claims 1 to 3, wherein said authentication server is integrated in said web server, said method comprising the steps of, for any request for a web page, - request the identifier at token (303), - transmitting a session request request containing the identifier of said token to said authentication server (305), - transmitting the session request returned by said authentication server to said token (307), - checking by said token the validity of said session request (308), - transmitting the session response of said token by a session verification request to said authentication server (310), - checking by said authentication server the session response of said token, to authenticate (311), and - repeat the previous steps when, after a predetermined duration of value, viewing of said web page is not completed.   The method of claim 4, wherein the session request request sent to said authentication server also contains the data of the authentication request of said web server, namely: the identifier of said web server; authentication request identifier of said web server, and - the signature of the authentication request of said web server.   7. Method according to claim 4, wherein the authentication result request sent to said web server contains: the identifier of said token, the identifier of the authentication request of said web server, the result of the authentication, and - the signature of the result of the authentication.   8. Method according to claim 4 or 5, wherein the session request returned by said authentication server, and to said token, contains: the identifier of said web server having requested the authentication, the identifier of authentication request of said web server, - the new session key, and - the signature of the session request.   The method of claim 4 or 5, wherein the session response returned by said token, and contained in said session verification request sent to said authentication server, contains the signature of the session response.   10. The method of claim 4 or 5, wherein said token permanently stores data including a unique identifier among all of said tokens, and for each of said web servers with which it can be identified: the identifier of said web server identifying the last authentication request of said web server, the current cryptographic key, and the previous cryptographic key.   11. The method of claim 4 or 5, wherein said authentication server permanently maintains a database containing a recording by web server and by token between which there is possible mutual authentication, and which contains: - the identifier said token, - the identifier of said web server, - the identifier of said last authentication request of said web server, - the current cryptographic key, and - the new cryptographic key.   The method of claim 4 or 5, wherein said current cryptographic key and said previous cryptographic key of said token are initialized to the same values as said current cryptographic key of said authentication server, and the new clecryptographic of said authentication server is initialized. to an empty value, these initializations taking place for a given web server and during an administration phase.   13. The method of claim 4 or 5, wherein said authentication server generates a new cryptographic key if it has an empty value, or uses the current value of the new key if it does not, when it sends said session request to said token, this key corresponding to that of said web server and said token being authenticated.   The method of claim 4 or 5, wherein said token decrypts said session request with said current key, and if said signature is correct: it transfers said current key into said previous key and then updates said current key with said new key key contained in said session request, the current key and the previous key corresponding to those of said web server, and if said signature is incorrect, it decrypts said session request with said previous key, and if the signature is correct, it transfers said current key into said previous key and then updates said current key with said new key contained in said session request, the current key and the preceding key corresponding to those of said web server.   The method of claim 4 or 5 wherein said authentication server decrypts said token session response with said new key, and if said signature is correct, it transfers the value of said new cryptographic key into said current key, and resets to an empty value said new cryptographic key, these keys corresponding to those of said web server and said token being authenticated.