EP1238322A2

EP1238322A2 - Computer system for application by accreditation access

Info

Publication number: EP1238322A2
Application number: EP00988927A
Authority: EP
Inventors: Yves Audebert
Original assignee: ActivCard SA
Current assignee: ActivIdentity Europe SA
Priority date: 1999-12-17
Filing date: 2000-12-15
Publication date: 2002-09-11
Also published as: US6988210B1; AU2526901A; CA2395374A1; FR2802666B1; CN1409836A; US7320139B2; FR2802666A1; WO2001044886A3; TW518489B; WO2001044886A2; KR20020084073A; US20060037066A1; JP2003517670A

Abstract

The invention concerns a system for executing a software whereof the access by a user is controlled by an accrediting data comprising a terminal (T), first storage means (F) associated with said software for storing at least a first accrediting data particular to said user, access-control means for authorising access to said software in response to a conformity between said first accrediting data and a second accrediting data applied via said terminal, and a security device (PSD) personal to said user, associated with said terminal, and comprising second storage means (M) for secure storage of said second accrediting data. The terminal (T) comprises, at least partly, means for managing the accrediting data (CMP) including means for reading said second accrediting data and transmitting to said access-control means in response to the presentation of a request for access to said software, and means for updating accrediting data for selectively controlling the generation and modification in said first (F) and second (M) storage means respectively a new accrediting data replacing the previously stored accrediting data.

Description

COMPUTER SYSTEM FOR APPLICATION BY ACCREDITATION ACCESS The invention relates to improvements made to computer systems in which the access of a user to one or more software, for example applications, is controlled by one or more flow-through data. The security of a computer system, in particular the security of access to software such as operating systems or applications (home banking, electronic commerce, etc.) relies on user authentication at means of static flow-through data which, most often, consists of a name assigned to the user ("login na e") and a static password. In the following, the term “computer system” is understood to mean any system comprising a personal computer, a telephone, a mobile telephone, a personal digital assistant, etc. allowing a user to run either a local application or the client part. of an application, for example in the context of a client-server architecture. Different authentication protocols based on the knowledge of a static password by a user are known:

- basic authentication: the password is transmitted in clear to a server-side authentication module;

- encrypted password: a session key is transmitted using a public key algorithm (for example of the DIFFE-HELLMAN type), which makes it possible to establish a secure channel between two entities, via which the password will be transmitted , without it being necessary for them to share a secret password beforehand;

- digest authentication: the client part of the application encrypts the password (or a digest of the password) by means of a hazard sent by the authentication module on the server side;

- Kerberos: flow-through data is transmitted to the user by the server-side authentication module, in encrypted form using the user's password, so that only the latter can use the flow-through data .

However, these static passwords are vulnerable on many points because they can be disclosed (password brought lawfully or fraudulently to the knowledge of a third person), broken when they are weak (password used repeatedly without modification , short password, dictionary attack), discovered by spying on a communication line or emulation of an authentication server, or even replayed by reproducing an authentication sequence. To overcome these drawbacks, it is known to use other mechanisms offering greater security than static passwords.

A first known solution consists in using dynamic passwords, that is to say passwords which are modified with each use. These passwords dynamic can be of the synchronous type (that is to say they are modified synchronously on the user side and on the server side, for example as a function of time and / or of the number of uses) or asynchronous (at each request of access, the server-side authentication module generates a different hazard or challenge which is transmitted on the user side to generate the dynamic password using an appropriate algorithm). In either case (synchronous and asynchronous passwords), secret keys are shared on the server side and the user side. On the user side, dynamic passwords can be generated by a personal security device (PSD) such as a smart card, a portable and secure electronic device ("token", etc.). Another solution uses public key cryptography systems, the user having a private key and the public key being certified by a certification authority. An authentication sequence using such a system can take place as follows:

- the user transmits a certificate (containing his username, public key, address, etc.) to the server;

- upon receipt of the certificate, the server authentication module generates and sends the user a hazard;

- the user signs the hazard using his private key;

- the authentication module checks the signed hazard using the public key and authenticates the user if there is consistency.

When used, these dynamic password or public key solutions replace the authentication mechanisms based on a static password or use an external authentication server.

It is also known to use a password server (SSO) by means of which, by a single authentication and authorization process, a user can access all of the computers and systems to which he is authorized to access, without the need to enter many different passwords. Once the user is authenticated, namely by authentication using a strong password (password comprising a large number of characters), he can ask the password server to execute an application. . The password server then loads into the user's terminal a set of data comprising the user's credentials for the required application, which allows the terminal to launch the execution of the application. However, this solution requires a specific authentication server (SSO) and is nevertheless based on a first authentication of the user vis-à-vis this server on the basis of a static password.

The invention aims to improve the security of the mechanisms by which, by means of static flow-through data (username, password, etc.), a user with a terminal can authenticate against software executed either locally in this terminal, or partly in this terminal and in a server to which this terminal is connected.

Another object of the invention is to provide a computer system comprising sophisticated mechanisms for controlling access to one or more applications and in which, in addition, the authentication protocol based on the sharing of secret flow-through data and The static between the client side and the server side of an application is not changed and the authentication module of the server side application remains unchanged. To this end, the subject of the invention is a computer system for the execution of at least one software whose access by a user is controlled by the supply of at least one flow-through datum allocated to said user, the said system comprising :

- at least one terminal comprising data processing means for executing said software at least in part, - first storage means associated with said software for storing at least one first flow-through data specific to said user,

access control means for authorizing access to said software in response to consistency between said first flow-through data stored in said first storage means and a second flow-through data applied via said terminal to said software, and

- At least one security device personal to said user, associated with said terminal, and comprising second storage means for the secure storage of said second flow-through data, characterized in that said terminal comprises at least in part flow-through data management means comprising:

means for reading and transmitting flow-through data for reading said second flow-through data stored in said second storage means, transmitting it to said access control means in response to the presentation of a request for access to said software, and means for updating flow-through data for selectively controlling the generation and loading in said first and said second means of memorizing respectively a new flow-through data in replacement of the flow-through data previously stored.

Preferably, the computer system according to the invention further comprises one or more of the following characteristics considered alone or in combination:

said access control means are adapted to authorize access to said software in response to an identity between said first and second flow-through data, - said second storage means are suitable for storing a first identification code of said user, said terminal comprises interface means for applying a second identification code to said personal security device, and access to said personal security device being authorized in response to an identity between said first and second identification codes,

- said flow-through data updating means are adapted to automatically generate and transmit said new flow-through data directly to said first and second storage means, without communication of said new flow-through data to said user, - said flow-through data management means are software means forming part of said software,

said flow-through data updating means are adapted to generate and load new flow-through data into said first and second storage means following an access authorization given by said access control means,

said flow-through data management means are software means independent of said software,

said flow-through data updating means are adapted to generate and load new flow-through data into said first and second storage means following validation of said identification code by said validation means,

- said flow-through data management means include means for dating and loading in at least one of said storage means the date on which a flow-through data is generated and inhibiting means for not authorizing the generation of new flow-through data by said updating means that after expiration of a period determined since the generation of said flow-through data stored in said storage means,

- said software is stored and executed entirely in said terminal for the local implementation of said application, - said system comprises at least one server and data transmission means between said terminal and said server, said software is stored and executed partly in said terminal and partly in said server, and said first storage means are associated with said server.

Other characteristics and advantages of the invention will emerge from the description which follows of various embodiments given solely by way of example and illustrated by the appended drawings in which: FIG. 1 is a general block diagram of a computer system according to a first embodiment of the invention in the case of an application executed partly in a terminal and partly in a server,

FIG. 2 is a block diagram of a first embodiment of the computer system of FIG. 1,

FIG. 3 is a functional diagram illustrating a first mode of updating the flow-through data in the computer system of FIG. 2,

FIG. 4 is a functional diagram illustrating a second mode of updating the flow-through data in the computer system of FIG. 2, FIG. 5 illustrates a second mode of execution of the computer system of FIG. 1,

FIG. 6 illustrates a mode of updating the flow-through data in the computer system of FIG. 5,

FIG. 7 illustrates a third embodiment of the computer system of FIG. 1,

FIG. 8 illustrates a fourth embodiment of the computer system of FIG. 1,

FIG. 9 illustrates a computer system according to a second embodiment of the invention in which one or more applications are executed locally in a terminal, and

FIG. 10 illustrates a mode of updating the flow-through data in the computer system of FIG. 9

Referring to Figure 1, the computer system shown comprises a terminal T which is connected, on the one hand to a personal security device PSD and, on the other hand, to an information system I via network R The personal security device PSD is connected to the terminal T by means L making it possible to ensure a bidirectional transmission of information between them

The terminal T can be constituted, for example, by a personal computer, a telephone, a mobile telephone, a personal digital assistant, etc. It is conventionally provided with user interface means, data processing means (microprocessor) and appropriate memories (not shown) Thanks to appropriate software ACC1, ACC2, ACCN, the terminal T is capable of executing applications A1, A2, An in connection, via the network R, with servers S ^ S ₂ , S _n respectively containing software ACS ^ ACS ₂ , ACS _n Of course, contrary to what has been represented, each server Si, S ₂ , S _n of the information system I could implement several applications In summary , the software of each application is distributed between the terminal T and one of the servers of the information system I the software of the application A1 consists of the software ACC1 and ACS _L the software of the application A2 by the software ACC2 and ACS ₂ , the software of the application An by the software ACCN and the software ACS _N.

The network R ensuring the transmission of bidirectional data between the terminal T and the servers S ^ S ₂ S _n of the information system I can be of any nature, for example the Internet.

Within the meaning of the present request, a personal security device PSD is a device owned and / or accessible (for example by personal identification PIN code or other) exclusively by an authorized user, and making it possible to securely store data therein. by offering security guarantees against reading and / or writing of data by an unauthorized person.

It can be, for example, a smart card, a portable electronic device electrically powered and comprising a limited number of inputs and outputs as well as software and hardware protection means preventing access to buses internal on which the data pass through the device. In the case of a smart card, for example, the means of connection L with the terminal T are constituted by a smart card reader which can be external or integrated into the terminal T.

As a variant, the personal security device can be produced in the form of software installed in the terminal T and making it possible to store data securely in the terminal, this data possibly being able to be encrypted. This embodiment does not provide the same degree of security as that offered by a smart card, but it nevertheless represents a significant improvement insofar as, as will be explained below, the credential data of the user can be changed automatically, and therefore often.

The personal security device PSD comprises a memory M in which the flow-through data specific to the user of the terminal T is stored and allowing the latter to implement the various applications A1, A2 An. These flow-through data assigned to the user consist for example of a user name and password specific to the application in question.

On the information system I side, the various servers S ,, S ₂ , S _n comprise files Fi, F ₂ F _n respectively in which the flow-through data of all the users authorized to access an application implemented are stored. by the server considered. This is how the flow-through data of the user of the terminal T are stored in the memory M and the file F _T as regards the application A1, in the memory M and the file F ₂ as regards the application A2, in the memory M and in the file F _N as regards the application An.

Of course, the computer system of FIG. 1 may include several terminals T connected by the network R to the information system I and intended to be used by different users. In order to execute an application (home banking, electronic commerce, etc.), a user launches this application on his terminal T. Access to the personal security device PSD may be subject to the provision by the user of a personal identification number PIN via his terminal T. Once the request for access to the PSD device has been accepted, the user's credentials relating to the application in question are read in the personal security device PSD and are transmitted to the server considered. The latter compares the flow-through data received from the terminal T with that contained in its flow-through data file and authorizes the execution of the application if there is a match. In order to ensure the management of the flow-through data with a view to authentication with respect to the applications A1, A2, An, as well as an update of these flow-through data, CMP software management means are provided for flow-through data. As will be described below, these CMP means are distributed between the terminal T and the servers S ^ S ₂ S _n assigned to the different applications. To ensure authentication vis-à-vis a given application, it is necessary, at the level of the terminal T, to read from the personal security device PSD the flow-through data relating to this application.

To do this, it is possible to replace the standard application software on the client or terminal side with modified application software which ensures the management of communications with the PSD device in addition to the standard characteristics of the application. This type of layout corresponds to the embodiment illustrated in FIG. 2.

It is also possible to use specific software which reads the flow-through data in the PSD device and transmits them to the application in question without modification of the standard application software on the client or terminal side. To do this, it is possible to use different solutions: emulating the keyboard, sending a message in which the flow-through data is contained, for example. This second solution corresponds to the embodiments of FIGS. 5, 7 and 8.

Reference will now be made to FIG. 2 in which, for reasons of simplicity, only one server S has been shown. In the embodiment of FIG. 2, the flow-through data management software appears, on the terminal side, as a modified application software on the ACC _M client side. The part of this software ensuring the management of flow-through data is represented by a circle CMP _C. On the S server side, the flow-through data management software is represented by a CMP _S circle: this software is that which exists as standard in any application to allow the modification of flow-through data of users or the loading of flow-through data relating to new users. CMP _C and CMP _S software, which part respectively of the ACC _M and ACS software, together form the CMP software for managing the flow-through data of FIG. 1.

According to the layout of FIG. 2, the software means for managing the flow-through data integrated into the application A have direct access to the personal security device PSD by means of the application software modified on the client side ACC, and to the file of flow-through data F from server S.

In order to allow a user running the application A to benefit from an improvement in the security of the authentication process, a PSD device devoid of flow-through data is given to it by a security administrator. This PSD device does not contain a static password.

The user connects his PSD device to his terminal T and initializes therein a personal identification number PIN.

The user then installs the modified client-side ACC _M application software in place of the standard client-side application software previously used. When using the ACC _M software for the first time to access the application, the user enters his personal identification number PIN to authorize access to the PSD device and then opens access to the application using the static flow-through data known to him that he used to use with his standard client-side application software. This current flow-through data is presented to the ACS server-side application software using the standard authentication protocol.

Once the application on the server side is open, the CMP _C part of the modified application software on the client side ACC _M generates a random password, presents a request to change the password to the CMP _S software on the server side, transmitting the new one. password, and then loads the static flow-through data, including the generated password and possibly the user name, into the PSD device. The new generated static password is then stored in the file F and in the memory M while being unknown to the user. This mechanism makes it possible to use strong passwords, that is to say complex passwords (words not included in a dictionary, difficult to memorize and therefore to imagine, etc.) and comprising a large number of characters. , which are much more resistant to attack than short passwords which, in practice, are used when they have to be remembered or keyed in by a user.

When the user next accesses the application, they only need to enter their personal PIN identification number at the terminal, the authentication process then being automatically ensured by reading flow-through data in the PSD device and transmission of these via CMP _C software to CMP _S software on the server side. During this authentication process, the flow-through data is only no time displayed on the terminal T screen and therefore remain unknown to the user, which enhances the security offered by the system.

Then, the update or the change of the static password can be ensured each time the application is considered as illustrated in FIG. 3, or periodically, for example every day, as illustrated in FIG. 4, or even on a specific request from the system administrator.

Referring to FIG. 3, the user formulates in 1 a request for access to an application X at the level of the terminal T and this is taken into account at 2 at the level of the server S. The user enters at 3 his personal identification number or PIN code via the terminal T and this is transmitted to the PSD device which performs in 4 a comparison of the number entered by the user with that stored in 5 in the PSD device.

If the PIN number entered by the user does not correspond to that stored in 5, the access request is refused at the terminal at 6, which leads at 7 to the abandonment of the request at the server S.

If the response to test 4 is positive, the PSD device reads at 8 the flow-through datum (static password) stored therein for the application X and this datum is transmitted via the terminal T to the server S where a comparison is performed in 9 with the flow-through data (static password) stored in the file F for the application X and the user considered (block 10). If the data compared in 9 do not match, access to the application X is refused at 11. Otherwise, access to the application X is authorized at 12 at the server S and the terminal T generates in 13 a new flow-through datum for the application X.

This new flow-through data (password generated randomly) is transmitted respectively to the server S and to the device PSD and at 14 and 15 it is stored respectively in the file F and in the memory M. The process ends at 16 and 17 by the execution or execution of the application X respectively at the level of the server S and of the terminal T.

As a variant, as shown in FIG. 4, the modification or updating of the flow-through data (static password) may be subject to the expiration of a predetermined period since the last change of this password. The process implemented is identical to that of FIG. 3 up to step 12 and will therefore not be described again.

After step 12, the terminal T initiates in 18 a process for changing flow-through data for the application X, which leads in 19 to reading in the device

PSD of the date on which the last flow-through data for application X was memorized in the PSD device. In 20, it is determined whether a minimum period, for example a day, has elapsed since the last update of the data. Flow. If this is not the case, it is not modified and we go directly to 21 and 22 to the progress or execution of the application in the server S and the terminal T.

If it is determined in step 20 that the minimum time allowed has elapsed, it is proceeded at 23 at the level of the terminal T to the generation of new flow-through data for the application X and this is memorized in 24 and 25 respectively in the file F of the server S and the memory M of the device PSD, with memorization of its date of update at least in the memory M of the device PSD.

The embodiment of the invention illustrated in FIG. 5 differs from that of FIG. 2 as regards the mode of implementation of the software means for managing flow-through data. On the terminal T side, the flow-through data management software is part of a DD data insertion software ("Drag and Drop") which is independent of the client-side application software or ACC terminal. On the information system I side, there is a CMS flow-through data management software module independent of the application software on the ACS server side and which manages the file F of flow-through data associated with the server S. The CMS module can be implemented in server S or in a server independent of it. As in the case of FIG. 2, it should be understood that the implementation of the invention does not imply any hardware and software modification at the level of the information system I. In the description which follows, it will be assumed that a user of the terminal T already has an authorization to access an application executed on the terminal side by the application software on the client side ACC and on the server side by the application software on the server side ACS. The user is also supposed to be in possession of flow-through data allowing him to authenticate himself vis-à-vis the application and to open it. In order to implement the improved security mechanisms according to the invention, the user is provided with a blank PSD device, that is to say without any credentials, by a security administrator.

The user then connects his PSD device to his terminal T and installs the DD software in his terminal. In addition, it initializes the personal identification number PIN controlling access to its personal security device PSD.

The old flow-through data are requested from the user and communicated to the CMS flow-through data management module by the DD software in order to authenticate the user. New flow-through data (static password) is generated by the DD software and transmitted to the CMS module, which updates the flow-through data file F, either directly or through the ACS software. These new flow-through data are not known to the user and may include a "strong" static password as described above. To use the application, the user launches the DD program, enters his personal identification number PIN to allow access to the PSD device and inserts at the ACC software the static flow-through data read by the DD software in the PSD device , for example by a "drag and drop" operation implemented by the DD software using a mouse. The mechanisms allowing by a "drag and drop" operation to introduce flow-through data contained in a personal security device PSD into an application software are described in the French patent application N ° 9915979 filed on December 17, 1999 by the Applicant for "Computerized device with improved accreditation access", which will be referred to for more details. When this flow-through data is loaded into the application software, it is not displayed on the terminal screen and remains unknown to the user.

The process for updating or modifying the flow-through data will now be described with reference to the functional diagram in FIG. 6. This process is implemented each time the user launches the DD software on the terminal T.

In 26, the user requests access to the DD software on his terminal T. In 27, he introduces his personal identification number PIN and, in 28, this is compared in the PSD device with the personal identification number PIN which is stored there in 29. If the two numbers do not match , access is refused in 30. If the two numbers match, a process for updating the flow-through data of the application X is initiated in 31. This process is translated into 32, at the CMS module, by a request authentication of the user for the application X and at 33 by reading the flow-through data of the user currently stored in the file F for the application X. At the same time, the process initiated at 31 leads to 34 at the reading in the PSD device, flow-through data of the user for the application X and these are transmitted via the terminal R to the CMS module.

At 35, a comparison is made therein between the data read at 33 in the file F and those read at 34 in the memory M of the device PSD. In the event of a discrepancy, authentication against the CMS module is refused in 36 and there will therefore be no modification of the flow-through data.

Otherwise, at 37 at the terminal T, the DD software generates a new flow-through datum for the application X. This new flow-through datum is stored at 38 in the file F via the CMS module and at 39 in the PSD device.

If the device PSD includes flow-through data relating to several different applications, the CMP part _T of the software DD then initiates at 40 a process for updating the flow-through data for the application Y, and so on for all the applications for which flow-through data are contained in the PSD device.

Of course, as described with reference to FIG. 4, the generation of new flow-through data (static password) may be subject to the expiration of a predetermined time since the generation and storage of the flow-through data currently stored. in the PSD device.

It should be noted that in this second embodiment of the invention, the connection of the terminal T to the CMS module is not a prerequisite for accessing the application. This is carried out as described with reference to FIG. 2 by sending flow-through data to the application software on the ACS server side and, if it cannot be accessed by the CMS module to modify the flow-through data, for example if the CMS module is implemented in a server other than the server S, the access to the application supported by the server S can nevertheless be carried out thanks to the unmodified flow-through data contained in the memory M and the file F. The updating days of this flow-through data will simply be deferred until a connection with the CMS module can be established during a new launch of the DD program. The device according to the invention therefore differs in all respects from password server systems which require the prior establishment of a connection of the terminal with this password server in order to allow access to an application. FIG. 7 illustrates an embodiment of the invention which differs from that of FIG. 5 only as regards the means of initialization and personalization of the system.

In the system of FIG. 7, a personalization tool T is provided, provided with flow-through data management software CMP _P allowing a security administrator to initialize flow-through data, relating to a user for a given application, in the file F of the server supporting the application in question and in the personal security device PSD intended for the user. This means that, in addition to the initial flow-through data, the personal identification code PIN is loaded into the PSD device by means of the personalization tool T. As a variant, the flow-through data of the user for the application in question can be initialized or updated by the security administrator directly using standard administration tools intended to define the rights of the user vis-à-vis the application.

In a second phase, the PSD device and the associated PIN code are given to the user by separate channels, as is conventional, in particular with regard to smart cards.

Then, the user connects his PSD device to his terminal T and loads the DD software into his terminal. To access an application, the user launches the DD software, enters their code

PIN to allow access to the PSD device then, as described above with reference to FIG. 5, using the DD software, introduces into the ACC software the flow-through data read in the PSD device by a "drag-and-drop" operation using of a mouse.

For the rest, the updating of the flow-through data is carried out periodically as described in connection with FIG. 5.

It should be noted that, as a variant, this initialization and personalization process could also be implemented in the case of a hardware and software architecture as described in FIG. 2, that is to say in the case where the flow-through data management software is an integral part of the ACC _M client side and ACS server side application software.

FIG. 8 illustrates an alternative embodiment of the initialization and personalization process of FIG. 7. In the case of FIG. 8, the flow-through data of the users are generated by a personalization tool under the command of an administrator of security and are stored, for each user, in an initial flow-through data file K associated with the flow-through data management module CMS. A blank PSD device, that is to say one containing no credential data, is given to the user by the security administrator. Through a separate channel, an initial authentication password, also stored in the K file, is transmitted to the user.

This connects the PSD device it received to terminal T and installs the DD software if necessary. On the other hand, the user assigns a personal identification number PIN to his PSD device. The user then connects to the flow-through data management module CMS using the DD software and authenticates himself vis-à-vis the latter by presenting the initial authentication password which has been communicated to him. Once the user has been authenticated, the CMS module loads into the DD software the initial flow-through data stored for the user considered in the file K. These initial flow-through data are transferred by the DD software to the PSD device where they are stored. In parallel, the initial flow-through data of the user are loaded by the CMS module in the file F, or updated in the latter if the user was already accredited for the application considered.

Then, as described with reference to FIGS. 5 to 7, it suffices for the user, to authenticate himself vis-à-vis the application, to enter his PIN code then to load into the ACC software, by means of the DD software, the flow-through data read by the latter in the PSD device. Of course, as in the previous examples, during this loading of flow-through data by a "drag-and-drop" operation by means of mouse and DD software, the flow-through data itself is not displayed on the terminal screen and is therefore not known to the user.

After initialization and customization, the updating of the flow-through data takes place as described with reference to FIGS. 5 and 7. FIG. 9 illustrates a second embodiment of the invention in which the application is executed purely locally in the terminal T by means of application software LA loaded therein. In this case, the file F of the flow-through data is stored in memory in the terminal T. The software CMP for management of flow-through data is also executed locally and is part of the data insertion software DD. This CMP software has direct access to the personal security device PSD, and access to the file F, either directly as shown, or through the application software LA.

Initially, a blank PSD device devoid of any flow-through data is given to the user by a security administrator. The user connects his PSD device to his terminal T, loads the DD software and assigns a personal identification code PIN to his PSD device.

The old credentials of the user for the LA application are then required in the DD software to authenticate the user. The DD software generates new flow-through data which is loaded into the PSD device and replaces the old flow-through data in the file F, either directly or in the evening via the LA application.

To access LA use, the user then just has to launch the DD program, enter his PIN code allowing access to the PSD device and load the flow-through data into the LA application software by an operation. of "drag and drop" as described with reference to FIGS. 5, 7 and 8, it being understood once again that the flow-through data are not displayed on the screen during this operation and therefore remain unknown to the user.

The process for updating the flow-through data within the framework of the computer system of FIG. 9 is illustrated by the functional diagram of FIG. 10. After having requested access to the DD software at 41a, the user enters his code

PIN in 41 b at the terminal T and this is transmitted to the PSD device which performs in 42 a comparison with the PIN code which is stored there in 43. In the event of a discrepancy, the request is rejected in 44.

Otherwise, the DD software initiates at 45 a process for updating the flow-through data for the application X. To this end, it reads at 46 the flow-through data stored for the application X in the file F and at 47 those stored for this same application X in the PSD device. These flow-through data are compared in 48 and, in the event of discrepancy, modification of the data is refused in 49. Otherwise, the DD software generates at 50 a new flow-through datum for the application X and this is stored at 51 in the file F and at 52 in the device PSD.

If the terminal T is equipped with software for several applications X, Y, etc., a new process for updating the flow-through data for the application Y is initiated in 53, and so on for all the applications.

It follows from the above that the system described allows the authentication of users by means of static flow-through data, and in particular of a static password, which remain unknown to the user. The user therefore does not have to remember a password and is therefore not tempted to write it down anywhere to remember it.

This static password can be complex and have the maximum length compatible with the application considered, since it does not have to be memorized by the user and entered by the latter in his terminal. In addition, this static password is updated periodically automatically, that is to say that this update is not subject to the discretion of the user. This static password, "strong" and renewed periodically, is stored in a personal security device for the user, of the chip card or similar type or of the purely software type, which offers a very high degree of protection against reading attempts. illicit data contained therein.

Finally, to access an application, the system described does not require the terminal to connect in real time to any server other than the one on which the application is possibly partially executed. Indeed, if in the embodiments of FIGS. 5, 7 and 8, the CMS module for managing flow-through data can be installed in a server independent of that in which the application is partly executed, it does not remain. unless the connection to this independent server is not necessary to access the application. The system described therefore differs fundamentally from password server systems.

On the other hand, the system described does not involve any modification at the level of the existing servers, the only modifications necessary concerning the software to be implemented in the terminal (s). The computer system described therefore makes it possible to considerably strengthen the security of existing systems using authentication by static flow-through data to access one or more applications. It goes without saying that the embodiments described are only examples and they could be modified, in particular by substitution of technical equivalents, without departing from the scope of the invention. Thus, for example, the updating of the flow-through data could be carried out, not as described during each access to an application or after a predetermined period of time has elapsed, but based on a number of events. A counter can be incremented on each authentication request or each access to the flow-through data. During each authentication request or each access to the flow-through data, the content of this counter is compared with a threshold value, and if this is reached, the flow-through data is modified. This threshold can be chosen so that the flow-through data update takes place during each successful authentication with an application as described with reference to FIG. 6.

It should be understood that the expression "flow-through data" used in the description and the claims denotes both the flow-through data proper (password, username,) used to authenticate vis-à-vis an application that one or more secret or private keys for calculating one or more flow-through data proper. The updating of the "flow-through data" referred to in the foregoing may therefore, depending on the case, relate to flow-through data proper and / or secret or private keys for calculating flow-through data itself.

Claims

1. Computer system for the execution of at least one software, the access of which by a user is controlled by the supply of at least one flow-through datum allocated to said user, said system comprising: - at least one terminal comprising means for data processing for the execution of said software at least in part,

first storage means associated with said software for storing at least one first flow-through data specific to said user,

- At least one security device personal to said user, associated with said terminal, and comprising second storage means for the secure storage of said second flow-through data, characterized in that said terminal (T) at least partially comprises management means flow-through data (CMP) including:

- means for reading and transmitting flow-through data for reading said second flow-through data stored in said second storage means (M) and transmitting it to said access control means in response to the presentation of a request for access to said access software, and

means for updating flow-through data for selectively controlling the generation and loading in said first (F) and said second (M) means of memorizing respectively a new flow-through data in replacement of the flow-through data previously stored.

2. System according to claim 1, characterized in that said access control means (9) are adapted to authorize access to said software in response to an identity between said first and second flow-through data.

3. System according to any one of claims 1 and 2, characterized in that said second storage means (M) are adapted to store a first identification code of said user, said terminal (T) comprises interface means for the application of a second identification code to said personal security device (PSD), access to said personal security device being authorized in response to an identity between said first and second identification codes (PIN).

4. System according to any one of claims 1 to 3, characterized in that said flow-through data updating means are adapted to automatically generate and transmit said new flow-through data directly to said first (F) and second storage means (M), without communication of said new flow-through data to said user.

5. System according to any one of claims 1 to 4, characterized in that said flow-through data management means (CMP) are software means forming part of said software (ACC1, ACS1; ACC2).

6. System according to claim 5, characterized in that said means for updating flow-through data (CMP) are adapted to generate and load new flow-through data in said first (F) and second (M) storage means consecutively to an access authorization given by said access control means.

7. System according to any one of claims 1 to 4, characterized in that said flow-through data management means (CMP) are software means independent of said software (ACC, ACS).

8. System according to claims 3 and 7, characterized in that said flow-through data updating means (CMP) are adapted to generate and load new flow-through data in said first (F) and second (M) storage means following validation of said identification code by said validation means.

9. System according to any one of claims 6 and 8, characterized in that said flow-through data management means (CMP) comprise means for dating and loading in at least one of said storage means (M) the date to which flow-through data is generated and inhibiting means (20) for authorizing the generation of new flow-through data by said updating means only after a period of time has elapsed since the generation of said stored flow-through data in said storage means (M).

10. System according to any one of claims 1 to 9, characterized in that said software is stored and executed entirely in said terminal (T) for the local implementation of said application.

11. System according to any one of claims 1 to 9, characterized in that it comprises at least one server (S) and means (R) for transmitting data between said terminal (T) and said server, in that that said software is stored and executed partly in said terminal (T) and partly in said server (S), and in that said first storage means (F) are associated with said server (S).