FR2802666A1 - Systeme informatique pour application a acces par accreditation - Google Patents
Systeme informatique pour application a acces par accreditation Download PDFInfo
- Publication number
- FR2802666A1 FR2802666A1 FR9915980A FR9915980A FR2802666A1 FR 2802666 A1 FR2802666 A1 FR 2802666A1 FR 9915980 A FR9915980 A FR 9915980A FR 9915980 A FR9915980 A FR 9915980A FR 2802666 A1 FR2802666 A1 FR 2802666A1
- Authority
- FR
- France
- Prior art keywords
- data
- flow
- software
- user
- terminal
- Prior art date
- Legal status (The legal status 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 status listed.)
- Granted
Links
- 238000013523 data management Methods 0.000 claims abstract description 11
- 230000004044 response Effects 0.000 claims abstract description 11
- 238000013475 authorization Methods 0.000 claims description 4
- 230000005540 biological transmission Effects 0.000 claims description 4
- 238000004891 communication Methods 0.000 claims description 4
- 238000010200 validation analysis Methods 0.000 claims description 4
- 102100039164 Acetyl-CoA carboxylase 1 Human genes 0.000 claims description 3
- 102100021641 Acetyl-CoA carboxylase 2 Human genes 0.000 claims description 3
- 101000677540 Homo sapiens Acetyl-CoA carboxylase 2 Proteins 0.000 claims description 3
- 101000894929 Homo sapiens Bcl-2-related protein A1 Proteins 0.000 claims description 3
- 238000012545 processing Methods 0.000 claims description 3
- 101710190443 Acetyl-CoA carboxylase 1 Proteins 0.000 claims 1
- 239000003112 inhibitor Substances 0.000 claims 1
- 230000003068 static effect Effects 0.000 description 27
- 238000000034 method Methods 0.000 description 18
- 230000008569 process Effects 0.000 description 18
- 230000015654 memory Effects 0.000 description 13
- 230000004048 modification Effects 0.000 description 9
- 238000012986 modification Methods 0.000 description 8
- 230000007246 mechanism Effects 0.000 description 7
- 238000010586 diagram Methods 0.000 description 6
- 238000007726 management method Methods 0.000 description 5
- IERHLVCPSMICTF-XVFCMESISA-N CMP group Chemical group P(=O)(O)(O)OC[C@@H]1[C@H]([C@H]([C@@H](O1)N1C(=O)N=C(N)C=C1)O)O IERHLVCPSMICTF-XVFCMESISA-N 0.000 description 3
- 108091006146 Channels Proteins 0.000 description 3
- 239000013317 conjugated microporous polymer Substances 0.000 description 3
- 230000006872 improvement Effects 0.000 description 3
- 210000003643 myeloid progenitor cell Anatomy 0.000 description 3
- 102100022094 Acid-sensing ion channel 2 Human genes 0.000 description 2
- 102100034318 Long-chain-fatty-acid-CoA ligase 5 Human genes 0.000 description 2
- 230000008901 benefit Effects 0.000 description 2
- 230000002457 bidirectional effect Effects 0.000 description 2
- 230000008859 change Effects 0.000 description 2
- 230000037431 insertion Effects 0.000 description 2
- 230000001360 synchronised effect Effects 0.000 description 2
- 241001269238 Data Species 0.000 description 1
- 101000901079 Homo sapiens Acid-sensing ion channel 2 Proteins 0.000 description 1
- 101000780205 Homo sapiens Long-chain-fatty-acid-CoA ligase 5 Proteins 0.000 description 1
- 101000780202 Homo sapiens Long-chain-fatty-acid-CoA ligase 6 Proteins 0.000 description 1
- QLDHWVVRQCGZLE-UHFFFAOYSA-N acetyl cyanide Chemical compound CC(=O)C#N QLDHWVVRQCGZLE-UHFFFAOYSA-N 0.000 description 1
- 230000003203 everyday effect Effects 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 230000002401 inhibitory effect Effects 0.000 description 1
- QHLFJSMAWAWVRU-UHFFFAOYSA-N n-(5-chloro-4-methyl-1,3-thiazol-2-yl)propanamide Chemical group CCC(=O)NC1=NC(C)=C(Cl)S1 QHLFJSMAWAWVRU-UHFFFAOYSA-N 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
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
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
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 name") 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: - I'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, I'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, caractérisé en ce que ledit système comprend: 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, et 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 oeuvre 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 I; 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... Il 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 Si, S2,..... SI contenant respectivement des logiciels ACSi, ACS2,..... ACS. Bien entendu, contrairement à ce qui a été représenté, chaque serveur S1, S2,..... S, du système d'information I pourrait mettre en oeuvre 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 ACS1, 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 S1, S2..... S, du système d'information I peut être de
nature quelconque, par exemple Intemet.
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 oeuvre 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 1, les différents serveurs Si, S2,..... Sn comprennent des fichiers F1, F2,..... F, respectivement dans lesquels sont stockées les données accréditives de l'ensemble des utilisateurs autorisés à accéder à une application mise en oeuvre 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 F1 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 Si, 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 ACCM, 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 celuici 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, I'accès à l'application X est refusé en 11. Dans le cas contraire, I'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 I'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 oeuvre est identique à celui de la figure 3 jusqu'à
I'étape 12 et ne sera donc pas décrit à nouveau.
Apres 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 1, 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 ceuvre 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 oeuvre 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 applicationexé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 oeuvre 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, I'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 oeuvre 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 déposée par la Demanderesse le même jour que la présente demande 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 oeuvre à chaque fois que l'utilisateur lance le logiciel DD sur le terminal T. En 26, I'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 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éde au module CMS pour modifier les données accréditives, par exemple si le module CMS est mis en oeuvre dans un autre serveur que le serveur S, I'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, I'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 oeuvre 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-adire 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, I'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 41b 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.
Il 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 (11)
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, caractérisé en ce que ledit système comprend: - au moins 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, et et 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 I à 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, ACSI; 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 oeuvre 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).
Priority Applications (11)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR9915980A FR2802666B1 (fr) | 1999-12-17 | 1999-12-17 | Systeme informatique pour application a acces par accreditation |
| US09/723,284 US6988210B1 (en) | 1999-12-17 | 2000-11-28 | Data processing system for application to access by accreditation |
| TW089125307A TW518489B (en) | 1999-12-17 | 2000-11-29 | Data processing system for application to access by accreditation |
| EP00988927A EP1238322A2 (fr) | 1999-12-17 | 2000-12-15 | Systeme informatique pour application a acces par accreditation |
| JP2001545914A JP2003517670A (ja) | 1999-12-17 | 2000-12-15 | 認可によってアクセスするアプリケーション向けのデータ処理システム |
| CA002395374A CA2395374A1 (fr) | 1999-12-17 | 2000-12-15 | Systeme informatique pour application a acces par accreditation |
| PCT/FR2000/003549 WO2001044886A2 (fr) | 1999-12-17 | 2000-12-15 | Systeme informatique pour application a acces par accreditation |
| CN00817145.9A CN1409836A (zh) | 1999-12-17 | 2000-12-15 | 通过鉴定数据访问应用的信息*** |
| 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 |
| US11/253,559 US7320139B2 (en) | 1999-12-17 | 2005-10-20 | Data processing system for application to access by accreditation |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR9915980A FR2802666B1 (fr) | 1999-12-17 | 1999-12-17 | Systeme informatique pour application a acces par accreditation |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| FR2802666A1 true FR2802666A1 (fr) | 2001-06-22 |
| FR2802666B1 FR2802666B1 (fr) | 2002-04-05 |
Family
ID=9553415
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR9915980A Expired - Lifetime FR2802666B1 (fr) | 1999-12-17 | 1999-12-17 | 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) |
Families Citing this family (52)
| 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 |
| DE10130493B4 (de) * | 2001-06-25 | 2006-11-09 | Brueninghaus Hydromatik Gmbh | Verfahren zur Freigabe eines Zugriffs auf ein elektronisches Steuergerät |
| GB2381423B (en) * | 2001-10-26 | 2004-09-15 | Ericsson Telefon Ab L M | Addressing mechanisms in mobile IP |
| US7865948B1 (en) * | 2001-12-03 | 2011-01-04 | Advanced Micro Devices, Inc. | Method and apparatus for restricted execution of security sensitive instructions |
| US7167919B2 (en) * | 2001-12-05 | 2007-01-23 | Canon Kabushiki Kaisha | Two-pass device access management |
| 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 |
| WO2004053667A2 (fr) * | 2002-12-12 | 2004-06-24 | Encentuate Pte Ltd | Systeme de gestion d'identite et de confirmation d'authentification |
| 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 |
| AU2004305800A1 (en) * | 2003-09-12 | 2005-03-31 | Emc Corporation | System and method providing disconnected authentication |
| ATE386972T1 (de) * | 2003-10-06 | 2008-03-15 | Nxp Bv | 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 |
| EP2166474B1 (fr) * | 2005-02-14 | 2018-04-04 | Panasonic Intellectual Property Management Co., Ltd. | Dispositif d'exécution d'application, procédé de gestion et programme |
| WO2006099081A2 (fr) * | 2005-03-10 | 2006-09-21 | Debix, Inc. | Le procede des systemes de gestion d'informations relatives aux comptes |
| 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 |
| WO2009077706A1 (fr) * | 2007-12-07 | 2009-06-25 | France Telecom | 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 |
| JP5052367B2 (ja) | 2008-02-20 | 2012-10-17 | 株式会社リコー | 画像処理装置、認証パッケージインストール方法、認証パッケージインストールプログラム、及び記録媒体 |
| 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 | 百度在线网络技术（北京）有限公司 | 一种签名服务器及其控制方法 |
| US8544735B2 (en) * | 2011-05-23 | 2013-10-01 | Mastercard International Incorporated | Combicard transaction method and system having an application parameter update mechanism |
| 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)
| 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)
| 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 |
-
1999
- 1999-12-17 FR FR9915980A patent/FR2802666B1/fr not_active Expired - Lifetime
-
2000
- 2000-11-28 US US09/723,284 patent/US6988210B1/en not_active Expired - Lifetime
- 2000-11-29 TW TW089125307A patent/TW518489B/zh active
- 2000-12-15 WO PCT/FR2000/003549 patent/WO2001044886A2/fr not_active Application Discontinuation
- 2000-12-15 EP EP00988927A patent/EP1238322A2/fr not_active Ceased
- 2000-12-15 JP JP2001545914A patent/JP2003517670A/ja active Pending
- 2000-12-15 CN CN00817145.9A patent/CN1409836A/zh active Pending
- 2000-12-15 KR KR1020027007779A patent/KR20020084073A/ko not_active Application Discontinuation
- 2000-12-15 AU AU25269/01A patent/AU2526901A/en not_active Abandoned
- 2000-12-15 CA CA002395374A patent/CA2395374A1/fr not_active Abandoned
-
2005
- 2005-10-20 US US11/253,559 patent/US7320139B2/en not_active Expired - Lifetime
Patent Citations (3)
| 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 (1)
| Title |
|---|
| LUCKHARDT N: "PASSWORT PORTFOLIO", CT MAGAZIN FUER COMPUTER TECHNIK,DE,VERLAG HEINZ HEISE GMBH., HANNOVER, no. 13, 21 June 1999 (1999-06-21), pages 72, XP000828972, ISSN: 0724-8679 * |
Also Published As
| Publication number | Publication date |
|---|---|
| EP1238322A2 (fr) | 2002-09-11 |
| KR20020084073A (ko) | 2002-11-04 |
| CA2395374A1 (fr) | 2001-06-21 |
| US6988210B1 (en) | 2006-01-17 |
| US7320139B2 (en) | 2008-01-15 |
| JP2003517670A (ja) | 2003-05-27 |
| CN1409836A (zh) | 2003-04-09 |
| WO2001044886A2 (fr) | 2001-06-21 |
| FR2802666B1 (fr) | 2002-04-05 |
| AU2526901A (en) | 2001-06-25 |
| TW518489B (en) | 2003-01-21 |
| US20060037066A1 (en) | 2006-02-16 |
| WO2001044886A3 (fr) | 2001-12-13 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| FR2802666A1 (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 | |
| CA2647248C (fr) | Procede et serveur de coffres-forts electroniques avec mutualisation d'informations | |
| FR2779018A1 (fr) | Terminal et systeme pour la mise en oeuvre de transactions electroniques securisees | |
| 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 | |
| WO2006056669A1 (fr) | Procede de securisation d'un terminal de telecommunication connecte a un module d'identification d'un utilisateur du terminal | |
| EP2180423B1 (fr) | Controle de l'utilisation de machines virtuelles | |
| WO2016207715A1 (fr) | Gestion securisee de jetons électroniques dans un telephone mobile. | |
| EP1413088B1 (fr) | Methode pour creer un reseau virtuel prive utilisant un reseau public | |
| EP2614491A1 (fr) | Procede simplifie de personnalisation de carte a puce et dispositif associe | |
| WO2009016327A2 (fr) | Gestion et partage de coffres-forts dematerialises | |
| 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 | |
| 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 | |
| EP0969347B1 (fr) | Procédé d'authentification pour accès protégés dans un système informatique en réseau | |
| 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 | |
| FR3114714A1 (fr) | Procédé d’accès à un ensemble de données d’un utilisateur. | |
| 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 | |
| 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 | |
| CH716287A2 (fr) | Procédé de traitement de données biométriques d'un individu, avec phases de calibrage et de contrôle et inscription, dans une blockchain, d'un résultat d'analyse. | |
| CH716293A2 (fr) | Procédé de signature décentralisée, sous contrôle biométrique et sous condition d'identification personnelle, d'une transaction destinée à une blockchain. | |
| FR2901380A1 (fr) | Support personnel de memoire de masse portatif et systeme informatique d'acces securise a un espace utilisateur via un reseau | |
| FR2888437A1 (fr) | Procede et systeme de controle d'acces a un service d'un fournisseur d'acces implemente sur un serveur multimedia, module, serveur, terminal et programmes pour ce systeme |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| CD | Change of name or company name |
Owner name: ACTIVIDENTITY EUROPE SA, FR Effective date: 20140221 |
|
| TP | Transmission of property |
Owner name: ASSA ABLOY AB, SE Effective date: 20150428 |
|
| PLFP | Fee payment |
Year of fee payment: 17 |
|
| PLFP | Fee payment |
Year of fee payment: 18 |
|
| PLFP | Fee payment |
Year of fee payment: 19 |
|
| PLFP | Fee payment |
Year of fee payment: 20 |