WO2001044886A2 - Systeme informatique pour application a acces par accreditation - Google Patents

Systeme informatique pour application a acces par accreditation Download PDF

Info

Publication number
WO2001044886A2
WO2001044886A2 PCT/FR2000/003549 FR0003549W WO0144886A2 WO 2001044886 A2 WO2001044886 A2 WO 2001044886A2 FR 0003549 W FR0003549 W FR 0003549W WO 0144886 A2 WO0144886 A2 WO 0144886A2
Authority
WO
WIPO (PCT)
Prior art keywords
data
flow
software
user
terminal
Prior art date
Application number
PCT/FR2000/003549
Other languages
English (en)
Other versions
WO2001044886A3 (fr
Inventor
Yves Audebert
Original Assignee
Activcard
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Activcard filed Critical Activcard
Priority to EP00988927A priority Critical patent/EP1238322A2/fr
Priority to CA002395374A priority patent/CA2395374A1/fr
Priority to KR1020027007779A priority patent/KR20020084073A/ko
Priority to AU25269/01A priority patent/AU2526901A/en
Priority to JP2001545914A priority patent/JP2003517670A/ja
Publication of WO2001044886A2 publication Critical patent/WO2001044886A2/fr
Publication of WO2001044886A3 publication Critical patent/WO2001044886A3/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • G06F21/12—Protecting executable software
    • G06F21/121—Restricting unauthorised execution of programs
    • G06F21/123—Restricting unauthorised execution of programs by using dedicated hardware, e.g. dongles, smart cards, cryptographic processors, global positioning systems [GPS] devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • G06F21/109—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM] by using specially-adapted hardware at the client
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2135—Metering

Definitions

  • 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.
  • 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:
  • the password is transmitted in clear to a server-side authentication module
  • 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;
  • a public key algorithm for example of the DIFFE-HELLMAN type
  • 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;
  • 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 .
  • 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).
  • secret keys are shared on the server side and 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.).
  • PSD personal security device
  • token portable and secure electronic device
  • 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;
  • the server authentication module upon receipt of the certificate, the server authentication module generates and sends the user a hazard
  • the authentication module checks the signed hazard using the public key and authenticates the user if there is consistency.
  • 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.
  • static flow-through data username, password, etc.
  • 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.
  • 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
  • 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
  • said first storage means are associated with said server.
  • 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
  • FIG. 10 illustrates a mode of updating the flow-through data in the computer system of FIG. 9
  • 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 2 , S n respectively containing software ACS ⁇ ACS 2 , ACS n
  • each server Si, S 2 , S n of the information system I could implement several applications
  • 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 2 , 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 2 S n of the information system I can be of any nature, for example the Internet.
  • 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.
  • 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.
  • 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.
  • 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.
  • the various servers S ,, S 2 , S n comprise files Fi, F 2 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 2 as regards the application A2, in the memory M and in the file F N as regards the application An.
  • 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.
  • 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.
  • 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.
  • CMP software management means are provided for flow-through data.
  • these CMP means are distributed between the terminal T and the servers S ⁇ S 2 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.
  • FIG. 2 in which, for reasons of simplicity, only one server S has been shown.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the modification or updating of the flow-through data 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.
  • 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
  • step 20 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 user requests access to the DD software on his terminal T.
  • 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.
  • 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.
  • 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.
  • 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.
  • the generation of new flow-through data 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.
  • 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.
  • 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.
  • CMP P flow-through data management software
  • the personal identification code PIN is loaded into the PSD device by means of the personalization tool T.
  • 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.
  • 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.
  • the user connects his PSD device to his terminal T and loads the DD software into his terminal.
  • the user launches the DD software, enters their code
  • 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.
  • 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.
  • an initial authentication password also stored in the K file, is transmitted to the user.
  • 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.
  • 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.
  • 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.
  • 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 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Technology Law (AREA)
  • Multimedia (AREA)
  • Computer Hardware Design (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Remote Sensing (AREA)
  • Radar, Positioning & Navigation (AREA)
  • Storage Device Security (AREA)
  • Information Transfer Between Computers (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

Ce système pour l'exécution d'un logiciel dont l'accès par un utilisateur est commandé par une donnée accréditive comprend un terminal (T), des premiers moyens de mémorisation (F) associés audit logiciel pour le stockage d'au moins une première donnée accréditive propre audit utilisateur, des moyens de contrôle d'accès pour autoriser l'accès audit logiciel en réponse à une cohérence entre ladite première donnée accréditive et une seconde donnée accréditive appliquée via ledit terminal, et un dispositif de sécurité (PSD) personnel audit utilisateur, associé audit terminal, et comportant des seconds moyens de mémorisation (M) pour le stockage sécurisé de ladite seconde donnée accréditive. Le terminal (T) comprend, au moins en partie, des moyens de gestion de données accréditives (CMP) comportant des moyens pour lire ladite seconde donnée accréditive et la transmettre auxdits moyens de contrôle d'accès en réponse à la présentation d'une demande d'accès audit logiciel, et des moyens de mise à jour de données accréditives pour commander sélectivement la génération et le chargement dans lesdits premiers (F) et seconds (M) moyens de mémorisation respectivement d'une nouvelle donnée accréditive en remplacement de la donnée accréditive précédemment mémorisée.

Description

SYSTEME INFORMATIQUE POUR APPLICATION A ACCES PAR ACCREDITATION L'invention concerne des perfectionnements apportés aux systèmes informatiques dans lesquels l'accès d'un utilisateur à un ou plusieurs logiciels, par exemple des applications, est commandé par une ou plusieurs données accréditives. La sécurité d'un système informatique, en particulier la sécurité de l'accès à des logiciels tels que des systèmes d'exploitation ou des applications (banque à domicile, commerce électronique, etc..) repose sur une authentification de l'utilisateur au moyen de données accréditives statiques qui, le plus souvent, consistent en un nom attribué à l'utilisateur ("login na e") et un mot de passe statique. Dans la suite, on entend par système informatique n'importe quel système comprenant un ordinateur personnel, un téléphone, un téléphone mobile, un assistant numérique personnel etc.. permettant à un utilisateur d'exécuter, soit une application locale, soit la partie client d'une application, par exemple dans le cadre d'une architecture client-serveur. Différents protocoles d'authentification basés sur la connaissance d'un mot de passe statique par un utilisateur sont connus :
- authentification de base : le mot de passe est transmis en clair à un module d'authentification côté serveur ;
- mot de passe chiffré : une clé de session est transmise en utilisant un algorithme à clé publique ( par exemple de type DIFFE-HELLMAN), ce qui permet d'établir un canal sécurisé entre deux entités, via lequel sera transmis le mot de passe, sans qu'il soit nécessaire que celles-ci partagent préalablement un mot de passe secret ;
- authentification par condensé : la partie client de l'application chiffre le mot de passe (ou un condensé du mot de passe) au moyen d'un aléa envoyé par le module d'authentification côté serveur ;
- Kerberos : les données accréditives sont transmises à l'utilisateur par le module d'authentification côté serveur, sous forme chiffrée au moyen du mot de passe de l'utilisateur, de sorte que seul ce dernier a le moyen d'utiliser les données accréditives.
Cependant, ces mots de passe statiques sont vulnérables sur de nombreux points car ils peuvent être divulgués (mot de passe porté licitement ou frauduleusement à la connaissance d'une tierce personne), cassés lorsqu'ils sont faibles (mot de passe utilisé répétitivement sans modification, mot de passe court, attaque au dictionnaire), découverts par espionnage d'une ligne de communication ou émulation d'un serveur d'authentification, ou encore rejoués en reproduisant une séquence d'authentification. Pour remédier à ces inconvénients, il est connu de faire appel à d'autres mécanismes offrant une plus grande sécurité que les mots de passe statiques.
Une première solution connue consiste à utiliser des mots de passe dynamiques, c'est-à-dire des mots de passe qui sont modifiés à chaque utilisation. Ces mots de passe dynamiques peuvent être du type synchrone (c'est-à-dire qu'ils sont modifiés de manière synchrone côté utilisateur et côté serveur, par exemple en fonction du temps et/ou du nombre d'utilisations) ou asynchrones (à chaque requête d'accès, le module d'authentification côté serveur génère un aléa ou challenge différent qui est transmis côté utilisateur pour générer le mot de passe dynamique au moyen d'un algorithme approprié). Dans l'un ou l'autre cas (mots de passe synchrones et asynchrones), des clés secrètes sont partagées côté serveur et côté utilisateur. Côté utilisateur, les mots de passe dynamiques peuvent être générés par un dispositif de sécurité personnel (PSD) tel qu'une carte à puce, un dispositif électronique portable et sécurisé ("token") , etc.... Une autre solution fait appel à des systèmes de cryptographie à clé publique, l'utilisateur possédant une clé privée et la clé publique étant certifiée par une autorité de certification. Une séquence d'authentification au moyen d'un tel système peut se dérouler de la manière suivante :
- l'utilisateur transmet un certificat (contenant son nom d'utilisateur, sa clé publique, son adresse, etc..) au serveur ;
- à réception du certificat, le module d'authentification du serveur génère et envoie à l'utilisateur un aléa ;
- l'utilisateur signe l'aléa au moyen de sa clé privée ;
- le module d'authentification vérifie l'aléa signé au moyen de la clé publique et authentifie l'utilisateur s'il y a cohérence.
Lorsqu'elles sont utilisées, ces solutions à mot de passe dynamique ou clé publique remplacent les mécanismes d'authentification basés sur un mot de passe statique ou font appel à un serveur d'authentification externe.
Il est également connu de faire appel à un serveur de mot de passe (SSO) au moyen duquel, par un processus unique d'authentification et d'autorisation, un utilisateur peut accéder à tous les calculateurs et systèmes auxquels il est autorisé à accéder, sans avoir besoin d'introduire de nombreux mots de passe différents. Une fois que l'utilisateur est authentifié, à savoir par une authentification faisant appel à un mot de passe fort (mot de passe comportant un grand nombre de caractères), il peut demander au serveur de mot de passe l'exécution d'une application. Le serveur de mot de passe charge alors dans le terminal de l'utilisateur un ensemble de données comprenant les données accréditives de l'utilisateur pour l'application requise, ce qui permet au terminal de lancer l'exécution de l'application. Néanmoins, cette solution nécessite un serveur d'authentification spécifique (SSO) et repose néanmoins sur une première authentification de l'utilisateur vis-à-vis de ce serveur sur la base d'un mot de passe statique.
L'invention vise à améliorer la sécurité des mécanismes par lesquels, au moyen de données accréditives statiques (nom d'utilisateur, mot de passe, etc.), un utilisateur doté d'un terminal peut s'authentifier vis-à-vis d'un logiciel exécuté soit localement dans ce terminal, soit pour partie dans ce terminal et dans un serveur auquel ce terminal est connecté.
Un autre but de l'invention est de fournir un système informatique comportant des mécanismes perfectionnés de contrôle d'accès à une ou plusieurs applications et dans lequel, en outre, le protocole d'authentification basé sur le partage d'une donnée accréditive secrète et statique entre le côté client et le côté serveur d'une application n'est pas modifié et le module d'authentification de l'application côté serveur demeure inchangé. A cet effet, l'invention a pour objet un système informatique pour l'exécution d'au moins un logiciel dont l'accès par un utilisateur est commandé par la fourniture d'au moins une donnée accréditive attribuée audit utilisateur, le dit système comprenant :
- au moins un terminal comportant des moyens de traitement de données pour l'exécution dudit logiciel au moins en partie, - des premiers moyens de mémorisation associés audit logiciel pour le stockage d'au moins une première donnée accréditive propre audit utilisateur,
- des moyens de contrôle d'accès pour autoriser l'accès audit logiciel en réponse à une cohérence entre ladite première donnée accréditive stockée dans lesdits premiers moyens de mémorisation et une seconde donnée accréditive appliquée via ledit terminal audit logiciel, et
- au moins un dispositif de sécurité personnel audit utilisateur, associé audit terminal, et comportant des seconds moyens de mémorisation pour le stockage sécurisé de ladite seconde donnée accréditive, caractérisé en ce que ledit terminal comprend au moins en partie des moyens de gestion de données accréditives comportant :
- des moyens de lecture et de transmission de donnée accréditive pour lire ladite seconde donnée accréditive stockée dans lesdits seconds moyens de mémorisation la transmettre auxdits moyens de contrôle d'accès en réponse à la présentation d'une demande d'accès audit logiciel, et - des moyens de mise à jour de données accréditives pour commander sélectivement la génération et le chargement dans lesdits premiers et lesdits seconds moyens de mémorisation respectivement d'une nouvelle donnée accréditive en remplacement de la donnée accréditive précédemment mémorisée.
De préférence, le système informatique selon l'invention comprend en outre une ou plusieurs des caractéristiques suivantes considérées seules ou en combinaison :
- lesdits moyens de contrôle d'accès sont adaptés pour autoriser l'accès audit logiciel en réponse à une identité entre lesdites première et seconde données accréditives, - lesdits seconds moyens de mémorisation sont adaptés pour stocker un premier code d'identification dudit utilisateur, ledit terminal comprend des moyens d'interface pour l'application d'un second code d'identification audit dispositif de sécurité personnel, et l'accès audit dispositif personnel de sécurité étant autorisé en réponse à une identité entre lesdits premier et second codes d'identification,
- lesdits moyens de mise à jour de données accréditives sont adaptés pour générer automatiquement et transmettre ladite nouvelle donnée accréditive directement auxdits premiers et seconds moyens de mémorisation, sans communication de ladite nouvelle donnée accréditive audit utilisateur, - lesdits moyens de gestion de données accréditives sont des moyens logiciels faisant partie dudit logiciel,
- lesdits moyens de mise à jour de données accréditives sont adaptés pour générer et charger une nouvelle donnée accréditive dans lesdits premiers et seconds moyens de mémorisation consécutivement à une autorisation d'accès donnée par lesdits moyens de contrôle d'accès,
- lesdits moyens de gestion de données accréditives sont des moyens logiciels indépendants dudit logiciel,
- lesdits moyens de mise à jour de données accréditives sont adaptés pour générer et charger une nouvelle donnée accréditive dans lesdits premiers et seconds moyens de mémorisation consécutivement à une validation dudit code d'identification par lesdits moyens de validation,
- lesdits moyens de gestion de données accréditives comprennent des moyens pour dater et charger dans l'un au moins desdits moyens de mémorisation la date à laquelle une donnée accréditive est générée et des moyens inhibiteurs pour n'autoriser la génération d'une nouvelle donnée accréditive par lesdits moyens de mise à jour qu'après écoulement d'un délai déterminé depuis la génération de ladite donnée accréditive stockée dans lesdits moyens de mémorisation,
- ledit logiciel est stocké et exécuté en totalité dans ledit terminal pour la mise en œuvre locale de ladite application, - ledit système comprend au moins un serveur et des moyens de transmission de données entre ledit terminal et ledit serveur, ledit logiciel est stocké et exécuté pour partie dans ledit terminal et pour partie dans ledit serveur, et lesdits premiers moyens de mémorisation sont associés audit serveur.
D'autres caractéristiques et avantages de l'invention ressortiront de la description qui va suivre de différents modes de réalisation donnés uniquement à titre d'exemple et illustrés par les dessins annexés sur lesquels : La figure 1 est un schéma bloc général d'un système informatique selon une première forme de réalisation de l'invention dans le cas d'une application exécutée pour partie dans un terminal et pour partie dans un serveur ,
La figure 2 est un schéma bloc d'un premier mode d'exécution du système informatique de la figure 1 ,
La figure 3 est un diagramme fonctionnel illustrant un premier mode de mise à jour des données accréditives dans le système informatique de la figure 2 ,
La figure 4 est un diagramme fonctionnel illustrant un deuxième mode de mise à jour des données accréditives dans le système informatique de la figure 2 , La figure 5 illustre un deuxième mode d'exécution du système informatique de la figure 1 ,
La figure 6 illustre un mode de mise à jour des données accréditives dans le système informatique de la figure 5 ,
La figure 7 illustre un troisième mode d'exécution du système informatique de la figure 1 ,
La figure 8 illustre un quatrième mode d'exécution du système informatique de la figure 1 ,
La figure 9 illustre un système informatique selon une deuxième forme de réalisation de l'invention dans laquelle une ou des applications sont exécutées localement dans un terminal , et
La figure 10 illustre un mode de mise à jour des données accréditives dans le système informatique de la figure 9
En se reportant à la figure 1 , le système informatique représenté comprend un terminal T qui est connecté, d'une part à un dispositif de sécurité personnel PSD et, d'autre part, à un système d'information I par l'intermédiaire d'un réseau R Le dispositif de sécurité personnel PSD est relié au terminal T par des moyens L permettant d'assurer une transmission bidirectionnelle d'information entre eux
Le terminal T peut être constitué, par exemple, par un ordinateur personnel, un téléphone, un téléphone mobile, un assistant numérique personnel, etc II est doté de manière conventionnelle de moyens d'interface avec l'utilisateur, de moyens de traitement de données (microprocesseur) et de mémoires appropriées (non représentés) Grâce à des logiciels appropriés ACC1, ACC2, ACCN, le terminal T est capable d'exécuter des applications A1 , A2, An en liaison, via le réseau R, avec des serveurs S^ S2, Sn contenant respectivement des logiciels ACS^ ACS2, ACSn Bien entendu, contrairement a ce qui a été représenté, chaque serveur Si, S2, Sn du système d'information I pourrait mettre en œuvre plusieurs applications En résumé, les logiciels de chaque application sont distribués entre le terminal T et l'un des serveurs du système d'information I le logiciel de l'application A1 est constitué par le logiciel ACC1 et ACSL le logiciel de l'application A2 par le logiciel ACC2 et ACS2, le logiciel de l'application An par le logiciel ACCN et le logiciel ACSN.
Le réseau R assurant la transmission de données bidirectionnelles entre le terminal T et les serveurs S^ S2 Sn du système d'information I peut être de nature quelconque, par exemple Internet.
Au sens de la présente demande un dispositif de sécurité personnel PSD est un dispositif détenu et/ou accessible (par exemple par code PIN d'identification personnel ou autre) exclusivement par un utilisateur autorisé, et permettant d'y stocker de manière sécurisée des données en offrant des garanties de sécurité contre la lecture et/ou l'écriture de données par une personne non autorisée.
Il peut s'agir, par exemple, d'une carte à puce, d'un dispositif portable électronique alimenté électriquement et comportant un nombre limité d'entrées et de sorties ainsi que des moyens de protection logiciels et matériels interdisant l'accès aux bus internes sur lesquels les données transitent dans le dispositif. Dans le cas d'une carte à puce, par exemple, les moyens de liaison L avec le terminal T sont constitués par un lecteur de carte à puce qui peut être extérieur ou intégré au terminal T.
En variante, le dispositif de sécurité personnel peut être réalisé sous forme d'un logiciel implanté dans le terminal T et permettant de stocker des données de manière sécurisée dans le terminal, ces données pouvant éventuellement être chiffrées. Ce mode de réalisation n'apporte pas le même degré de sécurité que celui offert par une carte à puce, mais il représente cependant une amélioration sensible dans la mesure où, comme cela sera expliqué dans la suite, les données accréditives de l'utilisateur peuvent être modifiées automatiquement, et donc souvent.
Le dispositif de sécurité personnel PSD comprend une mémoire M dans laquelle sont stockées les données accréditives propres à l'utilisateur du terminal T et permettant à celui-ci de mettre en œuvre les différentes applications A1 , A2 An. Ces données accréditives attribuées à l'utilisateur sont constituées par exemple d'un nom d'utilisateur et d'un mot de passe spécifique à l'application considérée.
Côté système d'information I, les différents serveurs S,, S2, Sn comprennent des fichiers Fi, F2 Fn respectivement dans lesquels sont stockées les données accréditives de l'ensemble des utilisateurs autorisés à accéder à une application mise en œuvre par le serveur considéré. C'est ainsi que les données accréditives de l'utilisateur du terminal T sont stockées dans la mémoire M et le fichier FT en ce qui concerne l'application A1 , dans la mémoire M et le fichier F2 en ce qui concerne l'application A2, dans la mémoire M et dans le fichier FN en ce qui concerne l'application An.
Bien entendu, le système informatique de la figure 1 peut comporter plusieurs terminaux T connectés par le réseau R au système d'information I et destinés à être utilisés par différents utilisateurs. Afin d'exécuter une application (banque à domicile, commerce électronique, etc.), un utilisateur lance cette application sur son terminal T. L'accès au dispositif de sécurité personnel PSD peut être subordonné à la fourniture par l'utilisateur d'un numéro d'identification personnel PIN via son terminal T. Une fois que la requête d'accès auprès du dispositif PSD a été acceptée, les données accréditives de l'utilisateur relatives à l'application considérée sont lues dans le dispositif de sécurité personnel PSD et sont transmises au serveur considéré. Celui-ci compare les données accréditives reçues du terminal T à celles contenues dans son fichier de données accréditives et autorise l'exécution de l'application s'il y a concordance. Afin d'assurer la gestion des données accréditives en vue d'une authentification vis-à-vis des applications A1 , A2, An, ainsi qu'une mise à jour de ces données accréditives, il est prévu des moyens logiciels CMP de gestion des données accréditives. Ainsi que cela sera décrit dans la suite, ces moyens CMP sont distribués entre le terminal T et les serveurs S^ S2 Sn affectés aux différentes applications. Pour assurer une authentification vis-à-vis d'une application donnée, il est nécessaire, au niveau du terminal T, de lire dans le dispositif de sécurité personnel PSD les données accréditives relatives à cette application.
Pour ce faire, il est possible de remplacer le logiciel d'application standard côté client ou terminal par un logiciel d'application modifié qui assure la gestion des communications avec le dispositif PSD en sus des caractéristiques standard de l'application. Ce type d'implantation correspond au mode d'exécution illustré par la figure 2.
Il est également possible d'utiliser un logiciel spécifique qui assure la lecture des données accréditives dans le dispositif PSD et les transmet à l'application considérée sans modification du logiciel d'application standard côté client ou terminal. Pour ce faire, il est possible de recourir à différentes solutions : émulation du clavier, envoi d'un message dans lequel les données accréditives sont contenues par exemple. Cette deuxième solution correspond aux formes d'exécution des figures 5, 7 et 8.
On se reportera maintenant à la figure 2 sur laquelle, pour des raisons de simplicité, un seul serveur S a été représenté. Dans le mode d'exécution de la figure 2, le logiciel de gestion des données accréditives se présente, côté terminal, comme un logiciel d'application modifié côté client ACCM. La partie de ce logiciel assurant la gestion des données accréditives est représentée par un cercle CMPC. Côté serveur S, le logiciel de gestion des données accréditives est représenté par un cercle CMPS : ce logiciel est celui qui existe de manière standard dans toute application pour permettre la modification des données accréditives des utilisateurs ou le chargement de données accréditives relatives à de nouveaux utilisateurs. Les logiciels CMPC et CMPS, qui font partie respectivement des logiciels ACCM et ACS, forment ensemble le logiciel CMP de gestion des données accréditives de la figure 1.
Selon l'implantation de la figure 2, les moyens logiciels de gestion des données accréditives intégrés à l'application A ont directement accès au dispositif de sécurité personnel PSD par l'intermédiaire du logiciel d'application modifié côté client ACC , et au fichier de données accréditives F du serveur S.
En vue de permettre à un utilisateur exécutant l'application A de bénéficier d'une amélioration de la sécurité du processus d'authentification, un dispositif PSD dépourvu de données accréditives lui est remis par un administrateur de sécurité. Ce dispositif PSD ne contient aucun mot de passe statique.
L'utilisateur connecte son dispositif PSD à son terminal T et initialise dans celui-ci un numéro d'identification personnel PIN.
L'utilisateur installe ensuite le logiciel d'application modifié côté client ACCM à la place du logiciel d'application standard côté client utilisé jusqu'alors. Lors de la première utilisation du logiciel ACCM pour accéder à l'application, l'utilisateur introduit son numéro d'identification personnel PIN pour autoriser l'accès au dispositif PSD et s'ouvre ensuite l'accès à l'application au moyen des données accréditives statiques connues de lui qu'il utilisait jusqu'alors avec son logiciel d'application standard côté client. Ces données accréditives en cours sont présentées au logiciel d'application côté serveur ACS au moyen du protocole d'authentification standard.
Une fois l'application côté serveur ouverte, la partie CMPC du logiciel d'application modifié côté client ACCM génère un mot de passe aléatoire, présente une requête de changement de mot de passe au logiciel CMPS côté serveur en lui transmettant le nouveau mot de passe, et charge alors les données accréditives statiques, comprenant le mot de passe généré ainsi éventuellement que le nom d'utilisateur, dans le dispositif PSD. Le nouveau mot de passe statique généré se trouve alors stocké dans le fichier F et dans la mémoire M tout en étant inconnu de l'utilisateur. Ce mécanisme permet d'utiliser des mots de passe forts, c'est-à-dire des mots de passe complexes (mots non compris dans un dictionnaire, difficiles à mémoriser et donc à imaginer, etc.) et comprenant un grande nombre de caractères, qui présentent une beaucoup plus grande résistance à des attaques que les mots de passe courts qui, en pratique, sont utilisés lorsqu'ils doivent être retenus ou introduits au clavier par un utilisateur.
Lors de l'accès suivant de l'utilisateur à l'application, il suffit à celui-ci d'introduire au terminal son numéro d'identification personnel PIN, le processus d'authentification étant ensuite assuré automatiquement par lecture des données accréditives dans le dispositif PSD et transmission de ces dernières via le logiciel CMPC au logiciel CMPS côté serveur. Pendant ce processus d'authentification, les données accréditives ne sont à aucun moment affichées sur l'écran du terminal T et demeurent donc inconnues de l'utilisateur, ce qui renforce la sécurité offerte par le système.
Ensuite, la mise à jour ou le changement du mot de passe statique peut être assurée à chaque accès à l'application considérée comme illustré à la figure 3, ou périodiquement, par exemple chaque jour, comme illustré à la figure 4, ou bien encore sur une requête spécifique de l'administrateur système.
En se reportant à la figure 3, l'utilisateur formule en 1 une requête d'accès à une application X au niveau du terminal T et celle-ci est prise en compte en 2 au niveau du serveur S. L'utilisateur introduit en 3 son numéro ou code d'identification personnel PIN via le terminal T et celui-ci est transmis au dispositif PSD qui effectue en 4 une comparaison du numéro introduit par l'utilisateur avec celui mémorisé en 5 dans le dispositif PSD.
Si le numéro PIN introduit par l'utilisateur ne correspond pas à celui mémorisé en 5, la requête d'accès est refusée au niveau du terminal en 6 ce qui conduit en 7 à l'abandon de la requête au niveau du serveur S.
Si la réponse au test 4 est positive, le dispositif PSD lit en 8 la donnée accréditive (mot de passe statique) mémorisée dans celui-ci pour l'application X et cette donnée est transmise via le terminal T au serveur S où une comparaison est effectuée en 9 avec la donnée accréditive (mot de passe statique) mémorisée dans le fichier F pour l'application X et l'utilisateur considéré (bloc 10). Si les données comparées en 9 ne concordent pas, l'accès à l'application X est refusé en 11. Dans le cas contraire, l'accès à l'application X est autorisé en 12 au niveau du serveur S et le terminal T génère en 13 une nouvelle donnée accréditive pour l'application X.
Cette nouvelle donnée accréditive (mot de passe généré aléatoirement) est transmise respectivement au serveur S et au dispositif PSD et en 14 et 15 elle est mémorisée respectivement dans le fichier F et dans la mémoire M. Le processus se termine en 16 et 17 par le déroulement ou exécution de l'application X respectivement au niveau du serveur S et du terminal T.
En variante, comme représenté à la figure 4, la modification ou mise à jour de la donnée accréditive (mot de passe statique) peut être subordonnée à l'écoulement d'un délai prédéterminé depuis le dernier changement de ce mot de passe. Le processus mis en œuvre est identique à celui de la figure 3 jusqu'à l'étape 12 et ne sera donc pas décrit à nouveau.
Après l'étape 12, le terminal T initie en 18 un processus de changement de donnée accréditive pour l'application X, ce qui conduit en 19 à la lecture dans le dispositif
PSD de la date à laquelle la dernière donnée accréditive pour l'application X a été mémorisée dans le dispositif PSD. En 20, il est déterminé si un délai minimum, par exemple une journée, s'est écoulé depuis la dernière mise à jour de la donnée accréditive. Si tel n'est pas le cas, celle-ci n'est pas modifiée et l'on passe directement en 21 et 22 au déroulement ou à l'exécution de l'application dans le serveur S et le terminal T.
S'il est déterminé à l'étape 20 que le délai minimum imparti s'est écoulé, il est procédé en 23 au niveau du terminal T à la génération d'une nouvelle donnée accréditive pour l'application X et celle-ci est mémorisée en 24 et 25 respectivement dans le fichier F du serveur S et la mémoire M du dispositif PSD, avec mémorisation de sa date de mise à jour au moins dans la mémoire M du dispositif PSD.
Le mode d'exécution de l'invention illustré par la figure 5 diffère de celui de la figure 2 en ce qui concerne le mode d'implantation des moyens logiciels de gestion des données accréditives. Côte terminal T, le logiciel de gestion des données accréditives fait partie d'un logiciel DD d'insertion de données ("Drag and Drop") qui est indépendant du logiciel d'application côté client ou terminal ACC. Côté système d'information I, il est prévu un module logiciel de gestion de données accréditives CMS indépendant du logiciel d'application côté serveur ACS et qui gère le fichier F des données accréditives associées au serveur S. Le module CMS peut être mis en œuvre dans le serveur S ou dans un serveur indépendant de celui-ci. Comme dans le cas de la figure 2, il doit être compris que la mise en œuvre de l'invention n'implique aucune modification matérielle et logicielle au niveau du système d'information I. Dans la description qui va suivre, on supposera qu'un utilisateur du terminal T dispose déjà d'une autorisation d'accès à une application exécutée côté terminal par le logiciel d'application côté client ACC et côté serveur par le logiciel d'application côté serveur ACS. L'utilisateur est supposé également être en possession de données accréditives lui permettant de s'authentifier vis-à-vis de l'application et d'ouvrir celle-ci. Afin de mettre en œuvre les mécanismes de sécurité améliorés suivant l'invention, l'utilisateur se voit doté par un administrateur de sécurité d'un dispositif PSD vierge, c'est-à-dire dépourvu de toutes données accréditives.
L'utilisateur connecte ensuite son dispositif PSD à son terminal T et installe le logiciel DD dans son terminal. De plus, il procède à l'initialisation du numéro d'identification personnel PIN commandant l'accès à son dispositif de sécurité personnel PSD.
Les anciennes données accréditives sont demandées à l'utilisateur et communiquées au module de gestion de données accréditives CMS par le logiciel DD afin d'authentifier l'utilisateur. De nouvelles données accréditives (mot de passe statique) sont générées par le logiciel DD et transmises au module CMS qui met à jour le fichier F de données accréditives, soit directement, soit par l'intermédiaire du logiciel ACS. Ces nouvelles données accréditives ne sont pas connues de l'utilisateur et peuvent comporter un mot de passe statique "fort" comme décrit précédemment. Pour utiliser l'application, l'utilisateur lance le programme DD, introduit son numéro d'identification personnel PIN pour permettre l'accès au dispositif PSD et insère au niveau du logiciel ACC les données accréditives statiques lues par le logiciel DD dans le dispositif PSD, par exemple par une opération de "glissé et lâché" (Drag and Drop) mise en œuvre par le logiciel DD au moyen d'une souris. Les mécanismes permettant par une opération de "glissé et lâché" d'introduire des données accréditives contenues dans un dispositif de sécurité personnel PSD dans un logiciel d'application sont décrites dans la demande de brevet français N°9915979 déposée le 17 décembre 1999 par la Demanderesse pour "Dispositif informatique à accès par accréditation perfectionné", à laquelle on se référera pour plus de détails. Lors de ce chargement des données accréditives dans le logiciel d'application, celles-ci ne sont pas affichées sur l'écran du terminal et demeurent inconnues de l'utilisateur.
Le processus de mise à jour ou de modification des données accréditives sera maintenant décrit en regard du diagramme fonctionnel de la figure 6. Ce processus est mis en œuvre à chaque fois que l'utilisateur lance le logiciel DD sur le terminal T.
En 26, l'utilisateur requiert sur son terminal T un accès au logiciel DD. En 27, il introduit sont numéro d'identification personnel PIN et, en 28, celui-ci est comparé dans le dispositif PSD avec le numéro d'identification personnel PIN qui s'y trouve mémorisé en 29. Si les deux numéros ne concordent pas, l'accès est refusé en 30. Si les deux numéros concordent, un processus de mise à jour des données accréditives de l'application X est initié en 31. Ce processus se traduit en 32, au niveau du module CMS, par une requête d'authentification de l'utilisateur pour l'application X et en 33 par une lecture des données accréditives de l'utilisateur actuellement stockées dans le fichier F pour l'application X. Parallèlement, le processus initié en 31 conduit en 34 à la lecture dans le dispositif PSD des données accréditives de l'utilisateur pour l'application X et celles-ci sont transmises via le terminal R au module CMS.
En 35 une comparaison est effectuée dans celui-ci entre les données lues en 33 dans le fichier F et celles lues en 34 dans la mémoire M du dispositif PSD. En cas de discordance, l'authentification vis-à-vis du module CMS est refusée en 36 et il ne sera donc pas procédé à une modification des données accréditives.
Dans le cas contraire, il est procédé en 37 au niveau du terminal T, par le logiciel DD, à la génération d'une nouvelle donnée accréditive pour l'application X. Cette nouvelle donnée accréditive est mémorisée en 38 dans le fichier F via le module CMS et en 39 dans le dispositif PSD.
Si le dispositif PSD comprend des données accréditives relatives à plusieurs applications différentes, la partie CMPT du logiciel DD initie ensuite en 40 un processus de mise à jour des données accréditives pour l'application Y, et ainsi de suite pour l'ensemble des applications pour lesquelles des données accréditives sont contenues dans le dispositif PSD.
Bien entendu, comme décrit en regard de la figure 4, la génération d'une nouvelle donnée accréditive (mot de passe statique) peut être subordonnée à l'écoulement d'un délai prédéterminé depuis la génération et la mémorisation de la donnée accréditive actuellement mémorisée dans le dispositif PSD.
Il est à noter que dans cette deuxième forme d'exécution de l'invention, la connexion du terminal T au module CMS n'est pas un préalable à l'accès à l'application. Celle-ci s'effectue comme décrit à propos de la figure 2 par envoi des données accréditives au logiciel d'application côté serveur ACS et, s'il ne peut pas être accédé au module CMS pour modifier les données accréditives, par exemple si le module CMS est mis en œuvre dans un autre serveur que le serveur S, l'accès à l'application supportée par le serveur S pourra néanmoins être effectué grâce aux données accréditives non modifiées contenues dans la mémoire M et le fichier F. La mise à jours de ces données accréditives se trouvera simplement différée jusqu'à ce qu'une connexion avec le module CMS puisse être établie lors d'un nouveau lancement du programme DD. Le dispositif selon l'invention diffère donc en tous points des systèmes à serveur de mot de passe qui nécessitent l'établissement préalable d'une connexion du terminal avec ce serveur de mot de passe pour permettre l'accès à une application. La figure 7 illustre un mode d'exécution de l'invention qui diffère de celui de la figure 5 uniquement en ce qui concerne les moyens d'initialisation et de personnalisation du système.
Dans le système de la figure 7, il est prévu un outil de personnalisation T doté d'un logiciel de gestion de données accréditives CMPP permettant à un administrateur de sécurité d'initialiser les données accréditives, relatives à un utilisateur pour une application donnée, dans le fichier F du serveur supportant l'application considérée et dans le dispositif de sécurité personnel PSD destiné à l'utilisateur. Cela signifie que, outre les données accréditives initiales, le code d'identification personnel PIN est chargé dans le dispositif PSD au moyen de l'outil de personnalisation T. En variante, les données accréditives de l'utilisateur pour l'application considérée peuvent être initialisées ou mises à jour par l'administrateur de sécurité directement au moyen d'outils d'administration standards prévus pour définir les droits de l'utilisateur vis-à-vis de l'application.
Dans une deuxième phase, le dispositif PSD et le code PIN qui lui est associé sont remis à l'utilisateur par des canaux séparés comme cela est classique, notamment en matière de carte à puce.
Ensuite, l'utilisateur connecte son dispositif PSD à son terminal T et charge le logiciel DD dans son terminal. Pour accéder à une application, l'utilisateur lance le logiciel DD, introduit son code
PIN pour permettre l'accès au dispositif PSD puis, comme décrit précédemment à propos de la figure 5, grâce au logiciel DD, introduit dans le logiciel ACC les données accréditives lues dans le dispositif PSD par une opération de "glissé-lâché" au moyen d'une souris.
Pour le reste, la mise à jours des données accréditives est effectuée périodiquement comme décrit à propos de la figure 5.
Il est à noter qu'en variante ce processus d'initialisation et de personnalisation pourrait être également mis en œuvre dans le cas d'une architecture matérielle et logicielle telle que décrite à la figure 2, c'est-à-dire dans le cas où le logiciel de gestion de données accréditives fait partie intégrante du logiciel d'application côté client ACCM et côté serveur ACS.
La figure 8 illustre une variante d'exécution du processus d'initialisation et de personnalisation de la figure 7. Dans le cas de la figure 8, les données accréditives des utilisateurs sont générées par un outil de personnalisation sous la commande d'un administrateur de sécurité et sont stockées, pour chaque utilisateur, dans un fichier de données accréditives initiales K associé au module de gestion de données accréditives CMS. Un dispositif PSD vierge, c'est-à-dire ne contenant aucune donnée accréditive, est remis à l'utilisateur par l'administrateur de sécurité. Par un canal séparé, un mot de passe d'authentification initial, également stocké dans le fichier K, est transmis à l'utilisateur.
Celui-ci connecte le dispositif PSD qu'il a reçu au terminal T et installe si nécessaire le logiciel DD. D'autre part, l'utilisateur affecte un numéro d'identification personnel PIN à son dispositif PSD. L'utilisateur se connecte ensuite au module de gestion de données accréditives CMS au moyen du logiciel DD et s'authentifie vis-à-vis de celui-ci en présentant le mot de passe d'authentification initial qui lui a été communiqué. Une fois l'utilisateur authentifié, le module CMS charge dans le logiciel DD les données accréditives initiales stockées pour l'utilisateur considéré dans le fichier K. Ces données accréditives initiales sont transférées par le logiciel DD au dispositif PSD où elles sont mémorisées. Parallèlement, les données accréditives initiales de l'utilisateur sont chargées par le module CMS dans le fichier F, ou mises à jour dans celui-ci si l'utilisateur était déjà accrédité pour l'application considérée.
Ensuite, comme décrit en regard des figures 5 à 7, il suffit à l'utilisateur, pour s'authentifier vis-à-vis de l'application, d'introduire son code PIN puis de charger dans le logiciel ACC, au moyen du logiciel DD, les données accréditives lues par ce dernier dans le dispositif PSD. Bien entendu, comme dans les exemples précédents, lors de ce chargement des données accréditives par une opération de "glissé-lâché" au moyen de la souris et du logiciel DD, les données accréditives proprement dites ne sont pas affichées sur l'écran du terminal et ne sont donc pas connues de l'utilisateur.
Après initialisation et personnalisation, la mise à jours des données accréditives s'opère comme décrit en regard des figures 5 et 7. La figure 9 illustre une deuxième forme de réalisation de l'invention dans laquelle l'application est exécutée de façon purement locale dans le terminal T au moyen d'un logiciel d'application LA chargé dans celui-ci. Dans ce cas, le fichier F des données accréditives est stocké en mémoire dans le terminal T. Le logiciel CMP de gestion de données accréditives est également exécuté en local et fait partie du logiciel DD d'insertion de données. Ce logiciel CMP a directement accès au dispositif de sécurité personnel PSD, et accès au fichier F, soit directement comme représenté, soit par l'intermédiaire du logiciel d'application LA.
Initialement, un dispositif PSD vierge dépourvu de toute donnée accréditive est remis à l'utilisateur par un administrateur de sécurité. L'utilisateur connecte son dispositif PSD à son terminal T, charge le logiciel DD et affecte un code d'identification personnel PIN à son dispositif PSD.
Les anciennes données accréditives de l'utilisateur pour l'application LA sont ensuite requises dans le logiciel DD pour authentifier l'utilisateur. Le logiciel DD génère de nouvelles données accréditives qui sont chargées dans le dispositif PSD et viennent remplacer les anciennes données accréditives dans le fichier F, soit directement, soir par l'intermédiaire de l'application LA.
Pour accéder à l'utilisation LA, il suffit ensuite à l'utilisateur de lancer le programme DD, d'introduire son code PIN permettant l'accès au dispositif PSD et de charger les données accréditives dans le logiciel d'application LA par une opération de "glissé-lâché" comme décrit en regard des figures 5, 7 et 8, étant entendu là encore que les données accréditives ne sont pas affichées à l'écran au cours de cette opération et demeurent par conséquent inconnues de l'utilisateur.
Le processus de mise à jour des données accréditives dans le cadre du système informatique de la figure 9 est illustré par le diagramme fonctionnel de la figure 10. Après avoir requis en 41a un accès au logiciel DD, l'utilisateur introduit son code
PIN en 41 b au niveau du terminal T et celui-ci est transmis au dispositif PSD qui procède en 42 à une comparaison avec le code PIN qui s'y trouve mémorisé en 43. En cas de discordance, la requête est rejetée en 44.
Dans le cas contraire, le logiciel DD initie en 45 un processus de mise à jour des données accréditives pour l'application X. A cet effet, il lit en 46 les données accréditives stockées pour l'application X dans le fichier F et en 47 celles stockées pour cette même application X dans le dispositif PSD. Ces données accréditives sont comparées en 48 et, en cas de discordance, la modification des données est refusée en 49. Dans le cas contraire, le logiciel DD génère en 50 une nouvelle donnée accréditive pour l'application X et celle-ci est stockée en 51 dans le fichier F et en 52 dans le dispositif PSD.
Si le terminal T est équipé de logiciels pour plusieurs applications X, Y, etc , un nouveau processus de mise à jour des données accréditives pour l'application Y est initié en 53, et ainsi de suite pour l'ensemble des applications.
Il résulte de ce qui précède que le système décrit permet l'authentification d'utilisateurs au moyen de données accréditives statiques, et notamment d'un mot de passe statique, qui demeurent inconnues de l'utilisateur. Celui-ci n'a donc pas à se souvenir d'un mot de passe et n'est donc pas tenté de l'écrire en un lieu quelconque pour s'en souvenir.
Ce mot de passe statique peut être complexe et avoir la longueur maximale compatible avec l'application considérée étant donné qu'il n'a pas à être mémorisé par l'utilisateur et introduit par celui-ci dans son terminal. De plus, ce mot de passe statique est mis à jour périodiquement de manière automatique, c'est-à-dire que cette mise à jour n'est pas soumise à la discrétion de l'utilisateur. Ce mot de passe statique "fort" et renouvelé périodiquement est stocké dans un dispositif de sécurité personnel à l'utilisateur, du type carte à puce ou similaire ou du type purement logiciel, qui offre un degré de protection très élevé contre les tentatives de lecture illicites des données qui y sont contenues.
Enfin, pour accéder à une application, le système décrit ne nécessite la connexion en temps réel du terminal à aucun serveur autre que celui sur lequel l'application est éventuellement en partie exécutée. En effet, si dans les modes de réalisation des figures 5, 7 et 8, le module CMS de gestion des données accréditives peut être implanté dans un serveur indépendant de celui dans lequel l'application est pour partie exécutée, il n'en demeure pas moins que la connexion à ce serveur indépendant n'est pas nécessaire pour accéder à l'application. Le système décrit se différencie donc fondamentalement des systèmes à serveur de mot de passe.
D'autre part, le système décrit n'entraîne aucune modification au niveau des serveurs existants, les seules modifications nécessaires concernant les logiciels à implanter dans le ou les terminaux. Le système informatique décrit permet donc de renforcer considérablement la sécurité de systèmes existants faisant appel à une authentification par données accréditives statiques pour accéder à une ou des applications. II va de soi que les modes de réalisation décrits ne sont que des exemples et l'on pourrait les modifier, notamment par substitution d'équivalents techniques, sans sortir pour cela du cadre de l'invention. C'est ainsi, par exemple, que la mise à jour des données accréditives pourrait être effectuée, non pas comme décrit lors de chaque accès à une application ou après écoulement d'un délai prédéterminé, mais en fonction d'un nombre d'événements. Un compteur peut être incrémenté à chaque requête d'authentification ou à chaque accès aux données accréditives. Lors de chaque requête d'authentification ou de chaque accès aux données accréditives, le contenu de ce compteur est comparé à une valeur de seuil, et si celle-ci est atteinte, les données accréditives sont modifiées. Ce seuil peut être choisi pour que la mise à jour des données accréditives ait lieu lors de chaque authentification réussie auprès d'une application comme décrit en regard de la figure 6.
Il doit être compris que l'expression "données accréditives" utilisée dans la description et les revendications désigne aussi bien les données accréditives proprement dites (mot de passe, nom d'utilisateur, ) servant à s'authentifier vis-à-vis d'une application qu'une ou des clés secrètes ou privées de calcul d'une ou plusieurs données accréditives proprement dites. La mise à jour des "données accréditives" dont il est question dans ce qui précède peut donc, suivant les cas, concerner des données accréditives proprement dites et/ou des clés secrètes ou privées de calcul de données accréditives proprement dites.

Claims

REVENDICATIONS
1. Système informatique pour l'exécution d'au moins un logiciel dont l'accès par un utilisateur est commandé par la fourniture d'au moins une donnée accréditive attribuée audit utilisateur, ledit système comprenant : - au moins un terminal comportant des moyens de traitement de données pour l'exécution dudit logiciel au moins en partie,
- des premiers moyens de mémorisation associés audit logiciel pour le stockage d'au moins une première donnée accréditive propre audit utilisateur,
- des moyens de contrôle d'accès pour autoriser l'accès audit logiciel en réponse à une cohérence entre ladite première donnée accréditive stockée dans lesdits premiers moyens de mémorisation et une seconde donnée accréditive appliquée via ledit terminal audit logiciel, et
- au moins un dispositif de sécurité personnel audit utilisateur, associé audit terminal, et comportant des seconds moyens de mémorisation pour le stockage sécurisé de ladite seconde donnée accréditive, caractérisé en ce que ledit terminal (T) comprend au moins en partie des moyens de gestion de données accréditives (CMP) comportant :
- des moyens de lecture et de transmission de donnée accréditive pour lire ladite seconde donnée accréditive stockée dans lesdits seconds moyens de mémorisation (M) et la transmettre auxdits moyens de contrôle d'accès en réponse à la présentation d'une demande d'accès audit logiciel, et
- des moyens de mise à jour de données accréditives pour commander sélectivement la génération et le chargement dans lesdits premiers (F) et lesdits seconds (M) moyens de mémorisation respectivement d'une nouvelle donnée accréditive en remplacement de la donnée accréditive précédemment mémorisée.
2. Système selon la revendication 1 , caractérisé en ce que lesdits moyens de contrôle d'accès (9) sont adaptés pour autoriser l'accès audit logiciel en réponse à une identité entre lesdites première et seconde données accréditives.
3. Système selon l'une quelconque des revendications 1 et 2, caractérisé en ce que lesdits seconds moyens de mémorisation (M) sont adaptés pour stocker un premier code d'identification dudit utilisateur, ledit terminal (T) comprend des moyens d'interface pour l'application d'un second code d'identification audit dispositif de sécurité personnel (PSD), l'accès audit dispositif personnel de sécurité étant autorisé en réponse à une identité entre lesdits premier et second codes d'identification (PIN).
4. Système selon l'une quelconque des revendications 1 à 3, caractérisé en ce que lesdits moyens de mise à jour de données accréditives sont adaptés pour générer automatiquement et transmettre ladite nouvelle donnée accréditive directement auxdits premiers (F) et seconds moyens de mémorisation (M), sans communication de ladite nouvelle donnée accréditive audit utilisateur.
5. Système selon l'une quelconque des revendications 1 à 4, caractérisé en ce que lesdits moyens de gestion de données accréditives (CMP) sont des moyens logiciels faisant partie dudit logiciel (ACC1 , ACS1 ; ACC2 ).
6. Système selon la revendication 5, caractérisé en ce que lesdits moyens de mise à jour de données accréditives (CMP) sont adaptés pour générer et charger une nouvelle donnée accréditive dans lesdits premiers (F) et seconds (M) moyens de mémorisation consécutivement à une autorisation d'accès donnée par lesdits moyens de contrôle d'accès.
7. Système selon l'une quelconque des revendications 1 à 4, caractérisé en ce que lesdits moyens de gestion de données accréditives (CMP) sont des moyens logiciels indépendants dudit logiciel (ACC, ACS).
8. Système selon les revendications 3 et 7, caractérisé en ce que lesdits moyens de mise à jour de données accréditives (CMP) sont adaptés pour générer et charger une nouvelle donnée accréditive dans lesdits premiers (F) et seconds (M) moyens de mémorisation consécutivement à une validation dudit code d'identification par lesdits moyens de validation.
9. Système selon l'une quelconque des revendications 6 et 8, caractérisé en ce que lesdits moyens de gestion de données accréditives (CMP) comprennent des moyens pour dater et charger dans l'un au moins desdits moyens de mémorisation (M) la date à laquelle une donnée accréditive est générée et des moyens inhibiteurs (20) pour n'autoriser la génération d'une nouvelle donnée accréditive par lesdits moyens de mise à jour qu'après écoulement d'un délai déterminé depuis la génération de ladite donnée accréditive stockée dans lesdits moyens de mémorisation (M).
10. Système selon l'une quelconque des revendications 1 à 9, caractérisé en ce que ledit logiciel est stocké et exécuté en totalité dans ledit terminal (T) pour la mise en œuvre locale de ladite application.
11. Système selon l'une quelconque des revendications 1 à 9, caractérisé en ce qu'il comprend au moins un serveur (S) et des moyens (R) de transmission de données entre ledit terminal (T) et ledit serveur, en ce que ledit logiciel est stocké et exécuté pour partie dans ledit terminal (T) et pour partie dans ledit serveur (S), et en ce que lesdits premiers moyens de mémorisation (F) sont associés audit serveur (S).
PCT/FR2000/003549 1999-12-17 2000-12-15 Systeme informatique pour application a acces par accreditation WO2001044886A2 (fr)

Priority Applications (5)

Application Number Priority Date Filing Date Title
EP00988927A EP1238322A2 (fr) 1999-12-17 2000-12-15 Systeme informatique pour application a acces par accreditation
CA002395374A CA2395374A1 (fr) 1999-12-17 2000-12-15 Systeme informatique pour application a acces par accreditation
KR1020027007779A KR20020084073A (ko) 1999-12-17 2000-12-15 인증 액세스에 의한 애플리케이션용 컴퓨터 시스템
AU25269/01A AU2526901A (en) 1999-12-17 2000-12-15 Computer system for application by accreditation access
JP2001545914A JP2003517670A (ja) 1999-12-17 2000-12-15 認可によってアクセスするアプリケーション向けのデータ処理システム

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR99/15980 1999-12-17
FR9915980A FR2802666B1 (fr) 1999-12-17 1999-12-17 Systeme informatique pour application a acces par accreditation

Publications (2)

Publication Number Publication Date
WO2001044886A2 true WO2001044886A2 (fr) 2001-06-21
WO2001044886A3 WO2001044886A3 (fr) 2001-12-13

Family

ID=9553415

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2000/003549 WO2001044886A2 (fr) 1999-12-17 2000-12-15 Systeme informatique pour application a acces par accreditation

Country Status (10)

Country Link
US (2) US6988210B1 (fr)
EP (1) EP1238322A2 (fr)
JP (1) JP2003517670A (fr)
KR (1) KR20020084073A (fr)
CN (1) CN1409836A (fr)
AU (1) AU2526901A (fr)
CA (1) CA2395374A1 (fr)
FR (1) FR2802666B1 (fr)
TW (1) TW518489B (fr)
WO (1) WO2001044886A2 (fr)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10130493A1 (de) * 2001-06-25 2003-01-30 Brueninghaus Hydromatik Gmbh Verfahren zur Freigabe eines Zugriffs auf ein elektronisches Steuergerät
CN1307502C (zh) * 2001-12-03 2007-03-28 先进微装置公司 对安全性敏感指令监控执行的方法与装置
CN100347989C (zh) * 2002-12-05 2007-11-07 佳能株式会社 双关卡设备访问管理
US8271792B2 (en) 2008-02-20 2012-09-18 Ricoh Company, Ltd. Image processing apparatus, authentication package installation method, and computer-readable recording medium

Families Citing this family (48)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2802666B1 (fr) * 1999-12-17 2002-04-05 Activcard Systeme informatique pour application a acces par accreditation
US7409700B1 (en) * 2000-11-03 2008-08-05 The Walt Disney Company System and method for enhanced broadcasting and interactive
GB2381423B (en) * 2001-10-26 2004-09-15 Ericsson Telefon Ab L M Addressing mechanisms in mobile IP
GB2384331A (en) * 2002-01-19 2003-07-23 Hewlett Packard Co Access control using credentials
US20030204732A1 (en) * 2002-04-30 2003-10-30 Yves Audebert System and method for storage and retrieval of a cryptographic secret from a plurality of network enabled clients
AU2003216032A1 (en) * 2002-12-12 2004-06-30 Encentuate Pte Ltd Identity management system for automatic user authentication
US8051470B2 (en) 2002-12-12 2011-11-01 International Business Machines Corporation Consolidation of user directories
US20040177258A1 (en) * 2003-03-03 2004-09-09 Ong Peng T. Secure object for convenient identification
US7325002B2 (en) * 2003-04-04 2008-01-29 Juniper Networks, Inc. Detection of network security breaches based on analysis of network record logs
CN1319314C (zh) * 2003-05-12 2007-05-30 明基电通股份有限公司 防止手机加密网络锁被破解的保护方法及相关装置
EP1486908A1 (fr) * 2003-06-12 2004-12-15 Axalto S.A. Carte à puce avec deux ports d'entrée/sortie pour la connexion des environnements sécurisés et non sécurisés
CN100432889C (zh) * 2003-09-12 2008-11-12 Rsa安全公司 提供断开鉴别的系统和方法
DE602004011965T2 (de) * 2003-10-06 2009-02-26 Nxp B.V. Verfahren und schaltung zum identifizieren und/oder verifizieren von hardware und/oder software eines geräts und eines mit dem gerät arbeitenden datenträgers
DE10359680A1 (de) * 2003-12-18 2005-07-14 Giesecke & Devrient Gmbh Verfahren zur Freischaltung eines Zugangs zu einem Computersystem oder zu einem Programm
US7581111B2 (en) * 2004-02-17 2009-08-25 Hewlett-Packard Development Company, L.P. System, method and apparatus for transparently granting access to a selected device using an automatically generated credential
US7581248B2 (en) * 2004-06-28 2009-08-25 International Business Machines Corporation Federated identity brokering
US20060031926A1 (en) * 2004-08-03 2006-02-09 Idan Shoham Method for reduced signon, using password synchronization instead of a credential database and scripts
SG121908A1 (en) * 2004-10-13 2006-05-26 Encentuate Pte Ltd A predictive method for multi-party strengthening of authentication credentials with non-real time synchronization
US8006288B2 (en) * 2004-11-05 2011-08-23 International Business Machines Corporation Method and apparatus for accessing a computer application program
US7500269B2 (en) * 2005-01-07 2009-03-03 Cisco Technology, Inc. Remote access to local content using transcryption of digital rights management schemes
US7340769B2 (en) * 2005-01-07 2008-03-04 Cisco Technology, Inc. System and method for localizing data and devices
US7533258B2 (en) * 2005-01-07 2009-05-12 Cisco Technology, Inc. Using a network-service credential for access control
BRPI0605904A (pt) * 2005-02-14 2007-12-18 Matsushita Electric Ind Co Ltd dispositivo de execução de aplicativo, método de gerenciamento, e programa
US7983979B2 (en) * 2005-03-10 2011-07-19 Debix One, Inc. Method and system for managing account information
US7831833B2 (en) * 2005-04-22 2010-11-09 Citrix Systems, Inc. System and method for key recovery
US7730181B2 (en) * 2006-04-25 2010-06-01 Cisco Technology, Inc. System and method for providing security backup services to a home network
GB0612775D0 (en) * 2006-06-28 2006-08-09 Ibm An apparatus for securing a communications exchange between computers
US9324082B2 (en) * 2007-07-06 2016-04-26 Ebay Inc. System and method for providing information tagging in a networked system
US8196191B2 (en) * 2007-08-17 2012-06-05 Norman James M Coordinating credentials across disparate credential stores
US8863246B2 (en) * 2007-08-31 2014-10-14 Apple Inc. Searching and replacing credentials in a disparate credential store environment
US20090077638A1 (en) * 2007-09-17 2009-03-19 Novell, Inc. Setting and synching preferred credentials in a disparate credential store environment
CZ306790B6 (cs) * 2007-10-12 2017-07-07 Aducid S.R.O. Způsob navazování chráněné elektronické komunikace mezi různými elektronickými prostředky, zejména mezi elektronickými prostředky poskytovatelů elektronických služeb a elektronickými prostředky uživatelů elektronických služeb
EP2232815B1 (fr) * 2007-12-07 2020-02-26 Orange Procédé de contrôle d'applications installées sur un module de sécurité associé à un terminal mobile, module de sécurité, terminal mobile et serveur associés
US20090172778A1 (en) * 2007-12-26 2009-07-02 Randall Stephens Rule-based security system and method
US20090199277A1 (en) * 2008-01-31 2009-08-06 Norman James M Credential arrangement in single-sign-on environment
US20090217367A1 (en) * 2008-02-25 2009-08-27 Norman James M Sso in volatile session or shared environment
US8402522B1 (en) * 2008-04-17 2013-03-19 Morgan Stanley System and method for managing services and jobs running under production IDs without exposing passwords for the production IDs to humans
US20100063932A1 (en) * 2008-09-08 2010-03-11 Jan Leonhard Camenisch Forming Credentials
US20100079239A1 (en) * 2008-09-29 2010-04-01 Riddhiman Ghosh Repurposing User Identity Tokens
US9665868B2 (en) 2010-05-10 2017-05-30 Ca, Inc. One-time use password systems and methods
US8607330B2 (en) * 2010-09-03 2013-12-10 International Business Machines Corporation Orderly change between new and old passwords
CN102567395A (zh) * 2010-12-30 2012-07-11 百度在线网络技术（北京）有限公司 一种签名服务器及其控制方法
WO2012162351A1 (fr) * 2011-05-23 2012-11-29 Mastercard International, Inc. Procédé et système de transactions combicard ayant un mécanisme de mise à jour de paramètres d'application
US8667569B2 (en) * 2011-09-29 2014-03-04 Target Brands, Inc. Credentials management
JP5773494B2 (ja) 2011-12-05 2015-09-02 インターナショナル・ビジネス・マシーンズ・コーポレーションＩｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ Ｃｏｒｐｏｒａｔｉｏｎ 情報処理装置、制御方法及びプログラム
EP2675106A1 (fr) * 2012-04-23 2013-12-18 ABB Technology AG Accès utilisateur à un dispositif de commande et d'automatisation industrielle
US9021563B2 (en) * 2013-01-02 2015-04-28 Htc Corporation Accessory interface system
US20180013755A1 (en) * 2016-07-08 2018-01-11 Microsoft Technology Licensing, Llc Logon using master password or turn-varying password

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2676291A1 (fr) * 1991-05-06 1992-11-13 Bull Sa Dispositif de securite pour systeme informatique et procede de reprise d'exploitation.
US5887065A (en) * 1996-03-22 1999-03-23 Activcard System and method for user authentication having clock synchronization
EP0929025A1 (fr) * 1998-01-13 1999-07-14 Nec Corporation Dispositif pour l'actualisation de mot de passe et support d'enregistrement utilisé pour celui-ci

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5471382A (en) * 1994-01-10 1995-11-28 Informed Access Systems, Inc. Medical network management system and process
US7124302B2 (en) * 1995-02-13 2006-10-17 Intertrust Technologies Corp. Systems and methods for secure transaction management and electronic rights protection
KR19990074117A (ko) * 1998-03-06 1999-10-05 윤종용 보안 카드 체크식 컴퓨터 보안 시스템 및 그 방법
FR2802666B1 (fr) * 1999-12-17 2002-04-05 Activcard Systeme informatique pour application a acces par accreditation

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2676291A1 (fr) * 1991-05-06 1992-11-13 Bull Sa Dispositif de securite pour systeme informatique et procede de reprise d'exploitation.
US5887065A (en) * 1996-03-22 1999-03-23 Activcard System and method for user authentication having clock synchronization
EP0929025A1 (fr) * 1998-01-13 1999-07-14 Nec Corporation Dispositif pour l'actualisation de mot de passe et support d'enregistrement utilisé pour celui-ci

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
LUCKHARDT N: "PASSWORT PORTFOLIO" CT MAGAZIN FUER COMPUTER TECHNIK,DE,VERLAG HEINZ HEISE GMBH., HANNOVER, no. 13, 21 juin 1999 (1999-06-21), page 72 XP000828972 ISSN: 0724-8679 *
See also references of EP1238322A2 *

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10130493A1 (de) * 2001-06-25 2003-01-30 Brueninghaus Hydromatik Gmbh Verfahren zur Freigabe eines Zugriffs auf ein elektronisches Steuergerät
DE10130493B4 (de) * 2001-06-25 2006-11-09 Brueninghaus Hydromatik Gmbh Verfahren zur Freigabe eines Zugriffs auf ein elektronisches Steuergerät
CN1307502C (zh) * 2001-12-03 2007-03-28 先进微装置公司 对安全性敏感指令监控执行的方法与装置
CN100347989C (zh) * 2002-12-05 2007-11-07 佳能株式会社 双关卡设备访问管理
US8271792B2 (en) 2008-02-20 2012-09-18 Ricoh Company, Ltd. Image processing apparatus, authentication package installation method, and computer-readable recording medium

Also Published As

Publication number Publication date
TW518489B (en) 2003-01-21
EP1238322A2 (fr) 2002-09-11
US20060037066A1 (en) 2006-02-16
CA2395374A1 (fr) 2001-06-21
FR2802666A1 (fr) 2001-06-22
FR2802666B1 (fr) 2002-04-05
AU2526901A (en) 2001-06-25
US6988210B1 (en) 2006-01-17
WO2001044886A3 (fr) 2001-12-13
KR20020084073A (ko) 2002-11-04
CN1409836A (zh) 2003-04-09
US7320139B2 (en) 2008-01-15
JP2003517670A (ja) 2003-05-27

Similar Documents

Publication Publication Date Title
WO2001044886A2 (fr) Systeme informatique pour application a acces par accreditation
EP1004100B1 (fr) Dispositif portable electronique pour systeme de communication securisee, et procede d'initialisation de ses parametres
EP3547203A1 (fr) Méthode et système de gestion d'accès à des données personnelles au moyen d'un contrat intelligent
FR2779018A1 (fr) Terminal et systeme pour la mise en oeuvre de transactions electroniques securisees
WO2006056669A1 (fr) Procede de securisation d'un terminal de telecommunication connecte a un module d'identification d'un utilisateur du terminal
EP0425053A1 (fr) Système de traitement de données comportant des moyens d'authentification d'une carte à mémoire, circuit électronique à utiliser dans ce système et procédé de mise en oeuvre de cette authentification
CN102822835B (zh) 个人便携式安全网络访问系统
EP1238340A2 (fr) Dispositif informatique pour l'application de donnees accreditives a un logiciel ou a un service
EP2180423B1 (fr) Controle de l'utilisation de machines virtuelles
EP1413088B1 (fr) Methode pour creer un reseau virtuel prive utilisant un reseau public
EP2183698A2 (fr) Gestion et partage de coffres-forts dematerialises
FR3114714A1 (fr) Procédé d’accès à un ensemble de données d’un utilisateur.
EP1299837A1 (fr) Procede de distribution commerciale en ligne de biens numeriques par l'intermediaire d'un reseau de communication et dispositif electronique d'achat de biens numeriques distribues par ce procede
EP2071799B1 (fr) Procédé et serveur pour l'accès a un coffre-fort électronique via plusieurs entités
FR2730076A1 (fr) Procede d'authentification par un serveur du porteur d'un objet portatif a microprocesseur, serveur et objet portatif correspondants
EP0969347B1 (fr) Procédé d'authentification pour accès protégés dans un système informatique en réseau
FR2913551A1 (fr) Methode d'authentification mutuelle et recurrente sur internet.
WO2022184726A1 (fr) Procédé pour permettre à des utilisateurs de déployer des contrats intelligents dans une chaîne de blocs au moyen d'une plateforme de déploiement
EP3029878B1 (fr) Procédé de transmission de secret à durée de vie limitée pour réaliser une transaction entre un terminal mobile et un équipement
WO2014135526A1 (fr) Système et procédé de gestion d'au moins une application en ligne, objet portable utilisateur usb et dispositif distant du système
FR3007929A1 (fr) Procede d'authentification d'un utilisateur d'un terminal mobile
WO2014135519A1 (fr) Système et procédé de gestion d'au moins une application en ligne, objet portable utilisateur communiquant par un protocole radioélectrique et dispositif distant du système
EP3899765A1 (fr) Réinitialisation d'un secret applicatif au moyen du terminal
FR3023039A1 (fr) Authentification d'un utilisateur
WO2012107369A1 (fr) Procede et dispositif de connexion a un service distant depuis un dispositif hote

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CR CU CZ DE DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
AK Designated states

Kind code of ref document: A3

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CR CU CZ DE DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A3

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

WWE Wipo information: entry into national phase

Ref document number: 2000988927

Country of ref document: EP

ENP Entry into the national phase

Ref country code: JP

Ref document number: 2001 545914

Kind code of ref document: A

Format of ref document f/p: F

WWE Wipo information: entry into national phase

Ref document number: 2395374

Country of ref document: CA

Ref document number: 008171459

Country of ref document: CN

WWE Wipo information: entry into national phase

Ref document number: 1020027007779

Country of ref document: KR

WWE Wipo information: entry into national phase

Ref document number: 25269/01

Country of ref document: AU

WWP Wipo information: published in national office

Ref document number: 2000988927

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 1020027007779

Country of ref document: KR

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

WWR Wipo information: refused in national office

Ref document number: 2000988927

Country of ref document: EP

WWW Wipo information: withdrawn in national office

Ref document number: 2000988927

Country of ref document: EP