EP2163030A2 - Procede de gestion d'acces - Google Patents

Procede de gestion d'acces

Info

Publication number
EP2163030A2
EP2163030A2 EP08806056A EP08806056A EP2163030A2 EP 2163030 A2 EP2163030 A2 EP 2163030A2 EP 08806056 A EP08806056 A EP 08806056A EP 08806056 A EP08806056 A EP 08806056A EP 2163030 A2 EP2163030 A2 EP 2163030A2
Authority
EP
European Patent Office
Prior art keywords
user
resource
access
management system
secret
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.)
Withdrawn
Application number
EP08806056A
Other languages
German (de)
English (en)
Inventor
Vincent Frey
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
France Telecom SA
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 France Telecom SA filed Critical France Telecom SA
Publication of EP2163030A2 publication Critical patent/EP2163030A2/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/104—Grouping of entities

Definitions

  • the invention relates to a data transmission method including a step of accessing a resource by a first user or at least a second user.
  • the term "user” may cover, for example, a natural person, an organization, a service, a resource or a process.
  • a request for access to a resource always relates to a single user.
  • the methods known from the state of the art are unusable when it is decided that a first user will have access to any resource if and only if at least a second user has previously requested access to the same resource as the first user.
  • An example would be the consultation of a will by all the legatees on the internet. The legatees can know the content of the will only from the moment all the legatees have requested access to it.
  • Another example would be the access to a telephone bridge by several users of the telephone bridge as soon as (and only if) all the users are ready, that is to say connected on the bridge.
  • the fact that the known methods are unusable in the situations described above has a disadvantage of the current state of the art.
  • the present invention aims to overcome this disadvantage by proposing to link access to a resource to a condition.
  • the method according to the invention is characterized in that said access to said resource is inhibited until said first and said second user have requested to access it.
  • the method is characterized in that it further comprises:
  • the method according to the invention has the advantage of allowing access to a resource if a first user requests access to it, as well as at least one second user.
  • the method is characterized in that it further comprises after said first access request step a step of notifying at least said second completion user of said first step.
  • the method is characterized in that it also comprises
  • a step of determining a code according to the specific information said access step being executed only in the case where said code corresponds to a reference specific to said resource.
  • the method is characterized in that it also comprises
  • the method is characterized in that said specific information is chosen by a resource manager.
  • the method is characterized in that said specific information is chosen by said users.
  • said specific information is chosen by said users.
  • a user can choose specific information that he can easily memorize.
  • the method is characterized in that the step of determining said code comprises a change of a variable as a function of said specific information.
  • the invention also relates to a management system comprising: means for authenticating a first user,
  • the invention also relates to a computer program, comprising program code instructions for performing at least one of the steps of a method described above, when said program is executed on a computer.
  • the invention also relates to a computer program product, comprising program code means, stored on a computer readable medium, for implementing at least one of the steps of a method as described above. when said program is running on a computer.
  • the invention also relates to a data carrier including a program as described above.
  • FIG. 1 represents a flowchart describing the steps of a method for accessing a resource according to the state of the art
  • FIG. 2 represents a flowchart describing the steps of a method for accessing a resource according to the invention.
  • An example of an authentication comprising only one step is the entry by a user of a code known by himself to a management system, for example a code
  • PI N in English: "personal identification number”
  • An example of an authentication comprising more than one step is an authentication divided into two steps: a so-called “identification” step and a so-called “authenticating” step itself.
  • the management system will ask a user to enter for example a login.
  • the management system will ask the user to enter a password, corresponding to the login.
  • This information (called the authorization) is stored in a management system G1 in a non-volatile memory, for example a database.
  • the management system G1 recognizes that the user U has the right to access the resource R1.
  • the management system G1 expects, during a step 13, to enter a specific code only known by the user U to authenticate it, in the broad sense of the word, with the management system G1.
  • the user enters his code, for example a PI N code known by him alone.
  • the system G1 can authenticate the user U. If the user U is not authenticated with the system G1, the process will remain in the step 13. If on the other hand, the user U is authenticated with the system G1, the process continues to a request step of access.
  • step 15 the user U requests access to the resource R1. Because the user U has been authorized before accessing the resource R1, the management system G1 or the resource R1 itself on call of the management system G1, authorizes access to the resource
  • the user U was not previously authorized to access the resource R1 and therefore does not have the rights to this resource R1, the user U will be authenticated but not authorized to access the resource R1. However, in this method above, the user U has access to the resource R1 yes or no independently of the steps of any other user.
  • I l is illustrated by the diagram of Figure 2. It is assumed that previously a first user U1 and at least a second user U2 have been authorized to access any resource R2 any.
  • the information concerning this authorization is stored in a management system G2 in a non-volatile memory M1, for example a database.
  • the G2 identity management system recognizes that the U1 and U2 users have the right to access the resource R2.
  • the user U1 and the user U2 belong to a group of users, previously created, who have a priori the right to access the resource R2.
  • U1 authenticates, during a step referenced 21, and requests, during a step referenced 23, access to the resource R2.
  • the management system G2 checks whether the two users U1 and U2 have requested access to the resource R2, in this case, if the other, second user U2 has also requested access to the resource R2.
  • the check may include checking the presence of a record of an access request by the user U2 in for example another memory M2 of the system G2. If this is not the case (the registration is not present), the management system G2 does not allow the user U1 access to the resource R2 and therefore the user U1 can not access to resource R2. However, the request, meanwhile, the user U1 is recorded, for example in the same memory M2 system G2.
  • the second user U2, in turn, now authenticates during a step referenced 25, and also requests, during a step referenced 27, access to the resource R2.
  • the method then checks during step 29 whether the two users U1 and U2 have requested access to the resource R2, so in this case, the presence of the record of the other (first) user U1 in the memory M2.
  • the result of the verification during the step 29 is now positive and the management system G2 authorizes, during an access step referenced 215, the two users U1 and U2 to access the resource R2.
  • a management system G2 recognizes that the users U1, U2, .., A have the right to access an resource R3.
  • the user U1, the user U2, ... and the user A belong to a group of users, previously created, who have a priori the right to access the resource R3.
  • the method verifies during a next verification step 215, if all the users U1,..., A have requested access to the resource R3. As soon as the result of the verification during step 29 is positive, the users U1,..., A can access the resource R3.
  • This step includes, for example, checking records in an M3 memory, requests from (n-1) users.
  • Each user U1,..., One in any order, must perform the steps 21 1 and 213 described above, synchronously or asynchronously, and without the need for the users to be physically located on the same site. location.
  • the user U1 authenticates with the management system G2 and at the moment when U1 requests access to the resource R3, the management system G2 indicates to U1 that it is waiting for the other users U2. , ..., One also request access to the resource R3. From this moment, the other users U2,..., A are notified by the management system G2. Once they have authenticated themselves and requested access to the resource, the management system allows U1 access to the resource R3. Meanwhile, the G2 management system allows other users U2, ..., One to access the resource R3.
  • the management system G2 asks him to provide a secret that is specific to this user. Then, the management system only authorizes access to the resource provided that all the users U1,..., One have each provided their respective secret to the management system G2 and after control by the management system G2 that the secrets provided are the secrets that are specific to the respective users.
  • the users U1,..., A obtain, for example, when they register beforehand with the management system G2 during a recording step, the secret which will be proper to them.
  • the secret can be chosen by a user himself or attributed to him by an R3 resource manager. In the latter case, the resource manager will therefore know the secrets of users U1, .., A.
  • the secret is for example a string of alphanumeric characters.
  • the channel is specific to the user and known only to him, that is to say not known to other users.
  • the secret that is unique to a user is a part of a cut of a complete secret that protects the resource R3.
  • the complete (or "global") secret that protects the R3 resource will be called later SR secret.
  • the step 29 of waiting includes, in this embodiment, not only the verification that all users U1, .., A have requested access to the resource R but also the control that the secrets SU1, .., SUn specific to the users U1, ..., Un have been provided In this embodiment, the access to the resource R3, as for it is protected by the management system
  • the secret SR would be produced by the notary as a resource manager (indeed, in the state of notarial practice, the notary has good access at any time in the will and therefore knows all the parts of the secret SR.
  • the secret SR would for example functionally closer to the combination of the trunk where the notary stores the will).
  • the management system G2 In order for the method according to the invention to operate, the management system G2 must know the following data:
  • the G2 management system obtains this data as follows:
  • the function C could for example be chosen by the person in charge of the resource R3, or could be registered in the management system G2 during its initialization.
  • the second asymmetric encryption function f also could for example be chosen by the person in charge of the resource R3, or could be registered in the management system G2 during its initialization.
  • a management system database might contain the array: ⁇ resource access permission R3, (SU1: 1), .., (SUn: n) ⁇ .
  • R3 resource access permission
  • (SU1: 1) indicates that the secret of the user U1 occupies the position 1 in the secret cut SR
  • (SUn: n) indicates that the secret of the user A occupies the position n in the SR secret.
  • the management system G2 therefore knows the position occupied by the secret SU1, .., SUn of each user.
  • C (SUi) be the result of an encryption of a secret of a user Ui.
  • the management system will include, for example, a database with the array: ⁇ C, (C (SUI): 1), .., (C (SUn): n) ⁇ .
  • This estimation is obtained in the following manner.
  • the management system G2 on the fly by the function f the result of the concatenation of all secret ciphers SUi users U1, .., One by the function C.
  • the concatenation is done by positioning each secret cipherment C (SUi) in its associated position, that is to say the position chosen by the resource manager for the secret of the user Ui.
  • the management system G2 could contain in a database the couple: ⁇ f, SR_crypted ⁇ .
  • SR_ciphered f (C (SUI), C (SU2), ..., C (SUn)) where C (SUI), C (SU2), ..., C (SUn) represents here the concatenation of all the ciphers of the secrets SUi of the users U1, .., A in setting each secret cipher C (Sui) to the position associated with the secret of the user Ui.
  • the management system Since the management system has stored f and SR_deleted, whoever provides all the parts SUi of the secret SR to the management system can access the resource R3. Indeed, if all SUi_fourni are communicated to the management system G2, the management system G2 can calculate the value of the result of the operation f (C (SU1_fourni), C (SU2_fourni), ..., C (SUn_fourni) ) and compare it with the value of SR_crypted it has stored.
  • the management system can give access to the resource R3 to the one who communicated all the Parties SuiJourni SR secret.
  • SR_file_funded f (C (SU1_provided), C (SU2_provided), ..., C (SUnavailable)) (because the management system G2 knows the position p of each secret part SUi in the cutting of the secret SR), and compare it to the stored SR_value it has stored to allow users to access the R3 resource.
  • the waiting step 29 is performed from a temporary variable V.
  • the resource manager logically breaks the SR secret into 4 parts.
  • the person in charge of the resource FS knows all the parts SU1, .., SU4 but the users U1, .., U4 each know only their part SU1, .., SU4 (that is to say their own secret) respectively . It is also possible that each user U1, ... U4 can choose his own secret SU1, ... SU4 and the resource manager does not know them.
  • the secrets SUi of the users U1, .., A can also be used during the authentication steps 21, 25, 211.
  • the management system after a request from a given user to access the resource R1 waits for another given user to request access to the resource R1.
  • the order could for example be U1, U2, U3 up to Un.
  • the condition can also be related to the time that can occur between two successive requests, for example after the request of a given first user to access the resource R1, the next user must request access within one hour. If the next user does not request access within one hour, the first user's request will be removed.
  • Other conditions or combinations of conditions can easily be contemplated by those skilled in the art.
  • the invention also provides that a user can withdraw his access request, for example if he has not been authorized to access the resource after a predetermined period of time.
  • the invention can also be generalized to the problem of strong authentication, considering that a single user has several secrets and it is necessary for him to provide all his secrets to access a resource.
  • It is also possible to link the access to the resource on the condition that a part of the users U1, .., A has requested access to it. For example, if n 10, only 7 users have requested access to the resource so that all 10 users can actually access it.
  • the conference call is a resource accessible by all the guests who are the users.
  • the conference call is protected by the identity management system as described in the operation of the invention.
  • the solution guarantees that the opening of the conference bridge will be done only when all the guests have asked to connect to it. In addition, it provides evidence that all guests attended the meeting.
  • a notary wants to be able to store the wills in electronic form and make the reading available on the internet.
  • the notary could have an intranet protected by a management system. The will is stored on the intranet and only he and the testator have the right to access it. This is done with traditional techniques. The day the testator dies, the notary sends an order to the management system, which then proposes to all the legatees to create an account (if it does not already exist) on the notary's intranet management system. . The secret protecting the will is then constructed as indicated in the operation of the invention. The invention guarantees that the will can be read by all the legatees via the internet provided that all have consented. The solution further provides evidence that reading to all legatees has been done.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Health & Medical Sciences (AREA)
  • Storage Device Security (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

L'invention concerne un procédé de transmission de données. Le procédé inclut une étape d'accès à une ressource par un premier utilisateur ou au moins un deuxième utilisateur. L'invention présente comme nouvelle caractéristique le fait que l'accès à ladite ressource est inhibé tant que ledit premier et ledit deuxième utilisateur n'ont pas demandé à y accéder.

Description

PROCEDE DE GESTI ON D'ACCES
L'invention concerne un procédé de transmission de données incluant une étape d'accès à une ressource par un premier utilisateur ou au moins un deuxième utilisateur.
Dans le cadre de ce document, l'expression "utilisateur" peut couvrir par exemple une personne physique, une organisation, un service, une ressource ou un processus. Dans l'état de la technique connu à l'instant, une demande d'accès à une ressource porte toujours sur un seul utilisateur. Les procédés connus de l'état de la technique sont inutilisables quand il est décidé qu'un premier utilisateur aura accès à une ressource quelconque si et seulement si au moins un deuxième utilisateur a préalablement demandé accès à la même ressource que le premier utilisateur. Un exemple serait la consultation d'un testament par tous les légataires sur internet. Les légataires peuvent connaître le contenu du testament seulement à partir du moment où tous ces légataires y ont demandé accès. Un autre exemple serait l'accès à un pont téléphonique par plusieurs utilisateurs du pont téléphonique dès que (et seulement si) tous les utilisateurs sont prêts, c'est-à-dire se sont connectés sur le pont. Le fait que les procédés connus soient inutilisables dans les situations décrites ci-dessus présente un inconvénient de l'état de la technique actuel.
La présente invention vise à palier cet inconvénient en proposant de lier l'accès à une ressource à une condition.
Le procédé selon l'invention est caractérisé en que ledit accès à ladite ressource est inhibé tant que ledit premier et ledit deuxième utilisateur n'ont pas demandé à y accéder. Dans une variante, le procédé est caractérisé en ce qu'il comprend en outre :
- une première étape d'authentification dudit premier utilisateur auprès d'un système de gestion,
- une première étape de demande d'accès à ladite ressource par ledit premier utilisateur,
- au moins une deuxième étape d'authentification dudit deuxième utilisateur auprès dudit système de gestion,
- au moins une deuxième étape de demande d'accès à ladite ressource par ledit deuxième utilisateur, et
- une étape d'attente jusqu'à ce que ladite première étape de demande d'accès et au moins ladite deuxième demande d'accès aient été exécutées. Le procédé selon l'invention présente l'avantage de permettre l'accès à une ressource si un premier utilisateur demande d'y accéder, ainsi qu'aussi au moins un deuxième utilisateur. Dans une variante, le procédé est caractérisé en ce qu'il comprend en outre après ladite première étape de demande d'accès - une étape de notification à au moins ledit deuxième utilisateur d'achèvement de ladite première étape.
De cette façon, le deuxième utilisateur sera maintenant au courant que le premier utilisateur a déjà demande accès. I l pourra donc agir en conséquence. Dans une variante, le procédé est caractérisé en ce qu'il comprend en outre
- une étape de saisie par lesdits utilisateurs d'une information spécifique aux dits utilisateurs, après lesdites étapes d'authentification, et
- une étape de détermination d'un code en fonction des informations spécifiques, ladite étape d'accès n'étant exécutée que dans le cas où ledit code correspond à une référence propre à ladite ressource.
Ceci présente comme avantage une sécurité améliorée à cause d'utilisation d'informations spécifiques en principe secrètes.
Dans une variante, le procédé est caractérisé en ce qu'il comprend en outre
- une étape de distribution au préalable desdites informations spécifiques aux dits utilisateurs. Dans une variante, le procédé est caractérisé en ce que lesdites informations spécifiques sont choisies par un responsable de ressource.
Ceci permettra une gestion centrale des informations spécifiques et de leur confidentialité.
Dans une variante, le procédé est caractérisé en ce que lesdites informations spécifiques sont choisies par lesdits utilisateurs. Avantageusement, un utilisateur pourra choisir une information spécifique qu'il peut facilement mémoriser.
Dans une variante, le procédé est caractérisé en ce que l'étape de détermination dudit code comprend un changement d'une variable en fonction desdites informations spécifiques.
L'invention concerne également un système de gestion comprenant : - des moyens d'authentification d'un premier utilisateur,
- des moyens de réception d'une demande d'accès à une ressource par ledit premier utilisateur,
- des moyens d'authentification d'au moins un deuxième utilisateur,
- des moyens de réception de demande d'accès à ladite ressource par ledit deuxième utilisateur, caractérisé en ce que ledit système (G2) comprend en outre
- des moyens d'attente jusqu'à ce que la première demande d'accès et au moins la deuxième demande d'accès aient été reçues, et
- des moyens d'autorisation d'accès par au moins un desdits premier utilisateur et deuxième utilisateur à ladite ressource.
L'invention concerne également un programme d'ordinateur, comprenant des instructions de code de programme pour l'exécution d'au moins l'une des étapes d'un procédé décrit ci- dessus, lorsque ledit programme est exécuté sur un ordinateur. L'invention concerne également un produit de programme d'ordinateur, comprenant des moyens de code de programme, stockés sur un milieu lisible par un ordinateur, pour mettre en œuvre au moins l'une des étapes d'un procédé comme décrit ci-dessus, lorsque ledit programme fonctionne sur un ordinateur.
L'invention concerne également un support de données incluant un programme comme décrit ci-dessus.
L'invention sera mieux comprise à l'aide de la description suivante, faite à titre d'exemple non-limitatif et en regard des dessins annexés, dans lesquels:
La figure 1 représente un ordinogramme décrivant les étapes d'un procédé pour accéder à une ressource selon l'état de la technique, et
La figure 2 représente un ordinogramme décrivant les étapes d'un procédé pour accéder à une ressource selon l'invention.
Dans le cadre de ce document, les mots "authentifier" et "authentification" seront utilisés au sens large et couvriront une authentification ne comprenant qu'une seule étape ainsi qu'une authentification comprenant plus d'une étape.
Un exemple d'une authentification ne comprenant qu'une seule étape est la saisie par un utilisateur d'un code connu par lui seul auprès d'un système de gestion, par exemple un code
PI N (en anglais : "personal identification number") . A partir du code, le système de gestion peut authentifier l'utilisateur.
Un exemple d'une authentification comprenant plus qu'une seule étape est une authentification divisée en deux étapes : une étape dite « d'identification » et une étape dite « d'authentification proprement dite ». Pendant l'étape dite « d'identification », le système de gestion demandera à un utilisateur de saisir par exemple un login. Pendant l'étape dite « d'authentification proprement dite », le système de gestion demandera à l'utilisateur de saisir un mot de passe, correspondant au login.
Dans le cas décrit à propos de la figure 1 , il est supposé que préalablement pendant une étape d'habilitation un utilisateur U a été habilité à accéder à une ressource R1 quelconque.
Cette information (appelée l'habilitation) est stockée dans un système de gestion G1 dans une mémoire non volatile, par exemple une base de données. Ainsi, le système de gestion G1 reconnaît que l'utilisateur U a le droit d'accéder à la ressource R1 .
Le système de gestion G1 attend, pendant une étape 13 la saisie d'un code spécifique seulement connu par l'utilisateur U pour l'authentifier, au sens large du mot, auprès du système de gestion G1 . Pendant une étape 13, l'utilisateur saisit son code, par exemple un code PI N connu par lui seul. A partir du code, le système G1 peut authentifier l'utilisateur U. Si l'utilisateur U n'est pas authentifié auprès le système G1 , le procédé restera dans l'étape 13. Si par contre, l'utilisateur U est authentifié auprès le système G1 , le procédé continue vers une étape 15 de demande d'accès.
Pendant l'étape 15, l'utilisateur U demande accès à la ressource R1 . Parce que l'utilisateur U a été habilité préalablement à accéder à la ressource R1 , le système de gestion G1 ou bien la ressource R1 elle-même sur appel du système de gestion G1 , autorise l'accès à la ressource
R1 et par conséquent, l'utilisateur U peut accéder à la ressource R1 . Si par contre, l'utilisateur
U n'était pas habilité préalablement à accéder à la ressource R1 et donc n'a pas les droits sur cette ressource R1 , l'utilisateur U sera authentifié mais pas autorisé à accéder à la ressource R1 . Toutefois, dans ce procédé ci-dessus, l'utilisateur U a accès à la ressource R1 oui ou non indépendamment des démarches de tout autre utilisateur.
Le procédé selon l'invention est expliqué dans ce qui suit. I l est illustré par le schéma de la figure 2. I l est supposé que préalablement un premier utilisateur U1 et au moins un deuxième utilisateur U2 ont été habilité à accéder à une ressource R2 quelconque. L'information concernant cette habilitation est stockée dans un système de gestion G2 dans une mémoire M1 non volatile, par exemple une base de données. Ainsi, le système de gestion de l'identité G2 reconnaît que les utilisateurs U1 et U2 ont le droit d'accéder à la ressource R2. L'utilisateur U1 et l'utilisateur U2 appartiennent donc à un groupe d'utilisateurs, préalablement crée, qui ont a priori le droit d'accéder a la ressource R2. Selon le procédé, U1 s'authentifie, pendant une étape référencée 21 , et demande, pendant une étape référencée 23, accès à la ressource R2. Pendant une étape 29 d'attente, le système de gestion G2 vérifie si les deux utilisateurs U1 et U2 ont demandé accès à la ressource R2 donc, dans ce cas présent, si l'autre, deuxième utilisateur U2 a également demandé accès à la ressource R2. La vérification peut comprendre le contrôle de la présence d'un enregistrement d'une demande d'accès par l'utilisateur U2 dans par exemple une autre mémoire M2 du système G2. Si cela n'est pas le cas (l'enregistrement n'est pas présent) , le système de gestion G2 n'autorise pas à l'utilisateur U1 l'accès à la ressource R2 et donc l'utilisateur U1 ne peut pas accéder à la ressource R2. Toutefois, la demande, quant à lui, de l'utilisateur U1 est enregistrée, par exemple dans la même mémoire M2 du système G2. Le deuxième utilisateur U2, à son tour, s'authentifie maintenant pendant une étape référencée 25, et demande, lui aussi, pendant une étape référencée 27, accès à la ressource R2. Le procédé vérifie ensuite pendant l'étape 29 si les deux utilisateurs U1 et U2 ont demandé accès a la ressource R2, donc dans le cas présent, la présence de l'enregistrement de l'autre (premier) utilisateur U1 dans la mémoire M2. Le résultat de la vérification pendant l'étape 29 est maintenant positif et le système de gestion G2 autorise, pendant une étape d'accès référencée 215, les deux utilisateurs U1 et U2 à accéder à la ressource R2. Dans le cas de N utilisateurs U1 , U2, ... , Un, au préalable, un système de gestion G2 reconnaît que les utilisateurs U1 , U2, .. , Un ont le droit d'accéder à une ressource R3. L'utilisateur U1 , l'utilisateur U2, ... et l'utilisateur Un appartiennent donc à un groupe d'utilisateurs, préalablement crée, qui ont a priori le droit d'accéder à la ressource R3. Les utilisateurs U1 , ... , Un s'authentifient individuellement pendant un étape 211 d'authentification auprès du système de gestion G2. Pendant une étape 213 ils demandent individuellement accès à la ressource. Le procédé vérifie pendant une étape 215 de vérification suivante, si tous les utilisateur U1 , ... , Un ont demandé l'accès à la ressource R3. Dès que le résultat de la vérification pendant l'étape 29 est positif, les utilisateurs U1 , ... Un peuvent accéder à la ressource R3. Cette étape comprend par exemple la vérification des enregistrements dans une mémoire M3, des demandes de (n-1 ) utilisateurs. Chaque utilisateur U1 , .. , Un dans n'importe quel ordre, doit effectuer les étapes 21 1 et 213 décrites ci-dessus, de manière synchrone ou asynchrone, et sans qu'il soit nécessaire que les utilisateurs soit physiquement localisés sur le même lieu.
Dans un mode de réalisation, l'utilisateur U1 s'authentifie auprès du système de gestion G2 et au moment où U1 demande l'accès à la ressource R3, le système de gestion G2 indique à U1 qu'il attend que les autres utilisateurs U2, ... , Un demandent eux aussi accès à la ressource R3. A partir de ce moment, les autres utilisateurs U2, ... , Un sont notifié par le système de gestion G2. Une fois qu'ils se sont à leur tour authentifiés et qu'ils ont demandé accès à la ressource, le système de gestion autorise à U1 l'accès à la ressource R3. Parallèlement, le système de gestion G2 autorise les autres utilisateurs U2, ... , Un à accéder à la ressource R3.
Dans un autre mode de réalisation, après qu'un utilisateur donné ait demandé accès à la ressource R3, le système de gestion G2 lui demande de fournir un secret qui est propre à cet utilisateur. Ensuite, le système de gestion n'autorise que l'accès à la ressource à condition que tous les utilisateurs U1 , ... , Un aient fourni chacun leur secret respectif au système de gestion G2 et après contrôle par le système de gestion G2 que les secrets fournis sont bien les secrets qui sont propres aux utilisateurs respectifs. Les utilisateurs U1 , .. , Un obtiennent, par exemple, lorsqu'ils s'enregistrent préalablement auprès du système de gestion G2 pendant une étape d'enregistrement, le secret qui leur sera propre. Le secret peut être choisi par un utilisateur-même ou lui être attribué par un responsable de ressource R3. Dans ce dernier cas, le responsable de ressource connaîtra donc les secrets des utilisateurs U1 , .. , Un. Le secret est par exemple une chaine de caractères alphanumériques. La chaine est spécifique pour l'utilisateur et connu de lui seulement, c'est-à-dire pas connu des autres utilisateurs. Le secret qui est propre à un utilisateur constitue une partie d'une découpe d'un secret complet qui protège la ressource R3. Le secret complet (ou "global") qui protège la ressource R3 sera appelé dans la suite secret SR. Le secret qui est propre à un utilisateur Ui donné (i = 1 , .. , n) ("sa partie du secret
SR" : les deux expressions seront utilisés dans la suite) sera désigné avec « SUi ». L'étape 29 d'attente comprend, dans ce mode de réalisation, non seulement la vérification que tous les utilisateurs U1 , .. , Un ont demande l'accès à la ressource R mais aussi le contrôle que les secrets SU1 , .. , SUn propres aux utilisateurs U1 , ..., Un ont été fournis. Dans ce mode de réalisation, l'accès à la ressource R3, quant à elle, est donc protégé par le système de gestion
G2 par le secret SR.
Dans le cas où, par exemple, la ressource R3 est un testament, le secret SR serait produit par le notaire en tant que responsable de ressource (en effet, dans l'état de la pratique notariale, le notaire a bien accès à tout moment au testament et donc connaît toutes les parties du secret SR. Le secret SR serait par exemple à rapprocher fonctionnellement de la combinaison du coffre ou le notaire stocke le testament) .
Dans le cas de l'accès à un pont téléphonique, c'est la plateforme de service qui héberge les ponts téléphoniques qui produirait le secret SR.
Pour que le procédé selon l'invention puisse fonctionner, le système de gestion G2 doit connaître les données suivantes :
- une première fonction de chiffrage asymétrique notée C,
- une deuxième fonction de chiffrage asymétrique notée f,
- la position p d'un secret SUi qui est propre à un utilisateur Ui dans la découpe du secret de la ressource SR, la position d'un tel secret sera notée (SUi : p),
- les résultats d'un chiffrage de tous les secrets SUi par la fonction C, ces résultats seront notée C(SUi) , et - le résultat du chiffrage croisé du secret de la ressource SR par les fonctions f et C, ce résultat sera notée SR_chiffré.
Le système de gestion G2 obtient ces données de façon suivante :
- La première fonction de chiffrage asymétrique C.
La fonction C pourrait par exemple être choisie par le responsable de la ressource R3, ou pourrait être enregistrée dans le système de gestion G2 lors de son initialisation.
- La deuxième fonction de chiffrage asymétrique f. La fonction f aussi pourrait par exemple être choisie par le responsable de la ressource R3, ou pourrait être enregistrée dans le système de gestion G2 lors de son initialisation. - La position p d'un secret SUi qui est propre à un utilisateur Ui dans la découpe du secret de la ressource SR : (SUi : p) .
Cest le responsable de la ressource qui découpe le secret de la ressource SR et choisit la position p dans cette découpe du secret SUi d'un utilisateur Ui. Pour simplifier l'explication, supposons que le responsable choisit dans la découpe du secret SR la position 1 pour le secret SU1 , la position 2 pour le secret SU2, ... et la position n pour le secret SUn. Le responsable de la ressource indique au système de gestion la position qu'il a choisie pour le secret de chaque utilisateur. Le responsable de la ressource R3 communique donc au système de gestion G2 par exemple un tableau d'association (secret d'utilisateur : position du secret de l'utilisateur dans la découpe du secret SR) . Ce tableau est stocké dans le système de gestion G2 et associé à la propriété "autorisation d'accès à la ressource R3". Par exemple, une base de données du système de gestion pourrait contenir le tableau : { autorisation d'accès à la ressource R3, (SU1 : 1 ) , .. , (SUn : n) } . Dans ce tableau, (SU1 : 1 ) indique que le secret de l'utilisateur U1 occupe la position 1 dans la découpe du secret SR, et (SUn : n) indique que le secret de l'utilisateur Un occupe la position n dans le secret SR. Le système de gestion G2 connaît donc la position qu'occupe le secret SU1 , .. , SUn de chaque utilisateur.
- Les résultats C(SUi) d'un chiffrage de tous les secrets SUi par la fonction G
Les utilisateurs fournissent au système de gestion G2 leur secret pendant l'étape d'enregistrement, et le système de gestion chiffre les secrets à la volée, de manière à ce que le système de gestion G2 ne connaisse que le résultat du chiffrement du secret qui est stocké dans une mémoire non volatile, une base de données par exemple. Notons C(SUi) le résultat d'un chiffrement d'un secret d'un utilisateur Ui. Dans ce cas, le système de gestion comprendra par exemple, une base de données avec le tableau : { C, ( C(SUI ) : 1 ) , .. , ( C(SUn) : n ) } .
- Le résultat SR_chiffré du chiffrage croisé du secret de la ressource SR par les fonctions f et C.
Ce chiffrage est obtenu de façon suivante. Une fois que tous les utilisateurs connaissent leur propre secret, le système de gestion G2 chiffre à la volée par la fonction f le résultat de la concaténation de tous les chiffrements des secrets SUi des utilisateurs U1 , .. , Un par la fonction C. La concaténation se fait en positionnant chaque chiffrement de secret C(SUi) dans sa position associée, c'est-à-dire la position choisie par le responsable de ressource pour le secret de l'utilisateur Ui. Le système de gestion G2 pourrait contenir dans une base de données le couple : { f, SR_chiffré } . Le résultat SR_chiffré a été calculé à la volée (c'est-à- dire que le système de gestion G2 ne connaît que le résultat SR_chiffré comme étant : SR_chiffré = f ( C(SUI ) , C(SU2) , ... , C(SUn) ) où C(SUI ) , C(SU2) , ..., C(SUn) représente ici la concaténation de tous les chiffrements des secrets SUi des utilisateurs U1 , .. , Un en positionnant chaque chiffrement de secret C(Sui) à la position associée au secret de l'utilisateur Ui.
D'autre part, la position p d'un secret SUi qui est propre à un utilisateur Ui dans la découpe du secret de la ressource SR n'est pas connue par celui-ci.
Puisque le système de gestion a stocké f et SR_chiffré, quiconque fournit tous les parties SUi du secret SR au système de gestion peut accéder à la ressource R3. En effet, si tous les SUi_fourni sont communiqués au système de gestion G2, le système de gestion G2 peut calculer la valeur du résultat de l'opération f ( C(SU1_fourni) , C(SU2_fourni) , ... , C(SUn_fourni) ) et le comparer avec la valeur de SR_chiffré qu'il a stocké. Si les deux valeurs sont égales, donc f ( C(SU1_fourni) , C(SU2_fourni) , ... , C(Sun_fourni) ) = SR_chiffré, le système de gestion peut donner accès à la ressource R3 à celui qui a communiqué tous les parties SUiJourni du secret SR. Puisque les utilisateurs U1 , .. , Un ne possèdent qu'une partie SUi du secret SR, un utilisateur ne peut pas accéder seul à la ressource R3, et il faut que tous les utilisateurs fournissent leur partie SUi du secret SR pour que le système de gestion G2 puisse recalculer SR_chiffré_fourni = f ( C(SU1_fourni) , C(SU2_fourni) , ... , C(SUn_fourni) ) (car le système de gestion G2 connaît la position p de chaque partie de secret SUi dans la découpe du secret SR) , et le comparer à la valeur SR_chiffré qu'il a stockée pour autoriser ou non les utilisateurs à accéder à la ressource R3.
Dans un mode de réalisation, l'étape 29 d'attente se réalise à partir d'une variable temporaire V. Dans ce cas, le variable temporaire V change en fonction des secrets fourni : V = f ( C(SU1_fourni) , C(SU2_fourni) , .... , C(SUn_fourni) ) . Si le secret n'est pas encore fourni sa valeur est positionnée à 0. Le système de gestion vérifie si V = SR_chiffré, par exemple, après chaque fois qu'un utilisateur a demandé l'accès à la ressource ou par exemple après écoulement d'une période de temps prédéfinie. Si l'égalité est réalisée, tous les utilisateurs ont accès à la ressource R3 à partir du même moment.
Voici un exemple qui illustre la théorie exposée ci-dessus.
Le responsable de la ressource découpe logiquement le secret SR en 4 parties. Les tailles des parties peuvent être égales ou inégales : par exemple l'utilisateur U1 peut très bien avoir un secret comprenant une chaine de 8 caractères tandis que l'utilisateur U3 a un secret comprenant une chaine de 80 caractères. Si une représentation hexadécimale du secret SR est # 12345 ABDCE00000 FFFFF, une découpe possible est SU1 = # 12345, SU2=#ABDCE, SU3=# 00000 et SU4= # FFFFF. Le responsable de la ressource FS connaît toutes les parties SU1 , .. , SU4 mais les utilisateurs U1 , .. , U4 ne connaissent chacun que leur partie SU1 , .. , SU4 (c'est-à-dire leur propre secret) respectivement. I I est aussi possible que chaque utilisateur U1 , ... U4 puisse choisir son propre secret SU1 , ... SU4 et le responsable de la ressource ne les connaisse pas.
I l est important que le système de gestion connaisse la position d'un secret dans la découpe du secret de la ressource. Reprenons l'exemple du secret SR ci-dessus, où le deuxième utilisateur U2 aura donc reçu la partie SU2=#ABDCE : quand cet utilisateur U2 demande accès à la ressource R3, il communique cette partie au système de gestion G2. Pour recalculer SR_chiffré Journi, et comme il sera compris par l'homme du métier, le système de gestion doit bien savoir que l'utilisateur U2 lui a fourni la deuxième partie. Si non, le système de gestion a à priori 4 ! = 24 combinaisons à essayer, ce qui compromettra sa rapidité de fonctionnement.
Comme il sera compris par l'homme du métier, les secrets SUi des utilisateurs U1 , .. , Un peuvent également être utilisés pendant les étapes d'authentification 21 , 25, 211 . Quand un utilisateur fournit un secret SUiJourni, le système de gestion vérifie pour cet utilisateur que C( SUiJourni) = C(SUi) . Si tel est le cas l'utilisateur est authentifié et l'étape 29 d'attente peut être enclenchée. Sinon, le système de gestion redemande à l'utilisateur de fournir son secret jusqu'à ce qu'il soit authentifié.
Dans un mode de réalisation, il y a une condition sur l'ordre de demandes d'accès des utilisateurs. Ce qui veut dire que le système de gestion, après la demande d'un utilisateur donné d'accéder à la ressource R1 attend qu'un autre utilisateur donné demande d'accéder à la ressource R1 . L'ordre pourrait par exemple être U1 , U2, U3 jusqu'à Un. La condition peut aussi être liée au temps qui peut se découler entre deux demandes successives, par exemple après la demande d'un premier utilisateur donné d'accéder à la ressource R1 , il faut que l'utilisateur prochain demande d'accéder dans une heure. Si l'utilisateur prochain ne demande pas accès dans une heure, la demande du premier utilisateur sera retirée. Des autres conditions ou combinaisons de conditions peuvent facilement être envisagées par l'homme du métier. L'invention prévoit également qu'un utilisateur puisse retirer sa demande d'accès, par exemple s'il n'a pas été autorisé à accéder à la ressource après une période de temps prédéterminée.
Dans un mode de réalisation, au lieu de plusieurs utilisateurs, l'invention peut également se généraliser à la problématique d'authentification forte, en considérant qu'un seul utilisateur dispose de plusieurs secrets et qu'il lui est nécessaire de fournir tous ses secrets pour accéder à une ressource.
I l est également possible de lier l'accès à la ressource à la condition que une partie des utilisateurs U1 , .. , Un y a demandé accès. Par exemple, si n = 10, il suffit que 7 utilisateurs aient demandés l'accès à la ressource pour que tous les 10 utilisateurs puissent effectivement y accéder.
Dans la suite seront décrits deux exemples d'application concrète du procédé selon l'invention.
EΞxemple 1 :
I I est décidé qu'une conférence téléphonique importante ne doit avoir lieu que si tous les invités sont présents.
La conférence téléphonique est une ressource accessible par l'ensemble des invités qui sont les utilisateurs. La conférence téléphonique est protégée par le système de gestion des identités comme décrit dans le fonctionnement de l'invention. La solution garantie que l'ouverture du pont de conférence ne se fera que lorsque tous les invités auront demandé de s'y connecter. Elle fournit en plus la preuve que tous les invités ont participé à la réunion.
Exemple 2:
Un notaire veut pouvoir stocker les testaments sous forme électronique et en rendre la lecture disponible par internet.
D'un point de vue juridique :
- lorsque le testateur est en vie, seul lui-même et le notaire ont droit d'y accéder - après le décès du testateur, le testament doit être lu devant tous les légataires par le notaire. Dans ce cas, le notaire pourrait disposer d'un intranet protégé par un système de gestion. Le testament est stocké sur l'intranet et seul lui et le testateur ont le droit d'y accéder. Cela se fait avec les techniques traditionnelles. Le jour où le testateur décède, le notaire envoie un ordre au système de gestion, qui propose ensuite à tous les légataires de se créer un compte (s'il n'existe pas déjà) sur le système de gestion de l'intranet du notaire. Le secret protégeant le testament est ensuite construit comme indiqué dans le fonctionnement de l'invention. L'invention garantie que le testament peut être lu par tous les légataires via internet sous condition que tous y ont consentis. La solution fournit en outre la preuve que la lecture devant tous les légataires a bien été effectuée.
Au lieu d'une concaténation, il est aussi possible de calculer le secret de la ressource SR à partir d'une autre relation fonctionnelle entre les secrets SUi des utilisateurs Ui et le secret de la ressource SR.
I I est aussi possible de distribuer deux (ou plus de) secrets SUi à un même utilisateur. Pour accéder à une ressource, cet utilisateur devra fournir tous les secrets qui lui sont attribués. De telle façon, et comme il sera compris par l'homme du métier, une protection plus forte de la ressource résulte.

Claims

REVEND I CATI ONS
1 ) Procédé de transmission de données incluant une étape d'accès à une ressource (R2; R3) par un premier utilisateur (U1 ) ou au moins un deuxième utilisateur (U2, .. , Un) , caractérisé en ce que ledit accès à ladite ressource (R2; R3) est inhibé tant que ledit premier et ledit deuxième utilisateur n'ont pas demandé à y accéder.
2) Procédé selon la revendication 1 , caractérisé en ce qu'il comprend en outre :
- une première étape (21 ; 21 1 ) d'authentification dudit premier utilisateur (U1 ) auprès d'un système de gestion (G2) ,
- une première étape (23; 213) de demande d'accès à ladite ressource (R2; R3) par ledit premier utilisateur,
- au moins une deuxième étape (25; 21 1 , 21 1 ) d'authentification dudit deuxième utilisateur (U2, .. , Un) auprès dudit système de gestion (G2) , - au moins une deuxième étape (27; 213, 213) de demande d'accès à ladite ressource (R2, R3) par ledit deuxième utilisateur (U2, .. , Un) , et
- une étape (29) d'attente jusqu'à ce que ladite première étape de demande d'accès et au moins ladite deuxième demande d'accès aient été exécutées.
3) Procédé selon la revendication 2, caractérisé en ce qu'il comprend en outre après ladite première étape (23; 213) de demande d'accès
- une étape de notification à au moins ledit deuxième utilisateur d'achèvement de ladite première étape.
4) Procédé selon la revendication 2, caractérisé en ce qu'il comprend en outre
- une étape de saisie par lesdits utilisateurs (U1 , U2, .. , Un) d'une information spécifique aux dits utilisateurs (U1 , U2, .. , Un) , après lesdites étapes (21 , 25; 21 1 ) d'authentification, et
- une étape de détermination d'un code en fonction des informations spécifiques, ladite étape d'accès (215) n'étant exécutée que dans le cas où ledit code correspond à une référence propre à ladite ressource (R2; R3) .
5) Procédé selon la revendication 4 caractérisé en ce qu'il comprend en outre
- une étape de distribution au préalable desdites informations spécifiques aux dits utilisateurs.
6) Procédé selon la revendication 5 caractérisé en ce que lesdites informations spécifiques sont choisies par un responsable de ressource. 7) Procédé selon la revendication 5 caractérisé en ce que lesdites informations spécifiques sont choisies par lesdits utilisateurs.
8) Procédé selon l'une quelconque de la revendication 4 à 6 caractérisé en ce que l'étape de détermination dudit code comprend un changement d'une variable en fonction desdites informations spécifiques.
9) Système de gestion (G2) comprenant :
- des moyens d'authentification d'un premier utilisateur (U1 ) , - des moyens de réception d'une demande d'accès à une ressource (R2; R3) par ledit premier utilisateur (U1 ) ,
- des moyens d'authentification d'au moins un deuxième utilisateur (U2, .. , Un) ,
- des moyens de réception de demande d'accès à ladite ressource (R2; R3) par ledit deuxième utilisateur (U2, .. , Un) , caractérisé en ce que ledit système (G2) comprend en outre
- des moyens d'attente jusqu'à ce que la première demande d'accès et au moins la deuxième demande d'accès aient été reçues, et
- des moyens d'autorisation d'accès par au moins un desdits premier utilisateur et deuxième utilisateur (U2, .. , Un) à ladite ressource (R2; R3) .
10) Programme d'ordinateur, comprenant des instructions de code de programme pour l'exécution d'au moins l'une des étapes d'un procédé conforme aux revendications 1 à 8, lorsque ledit programme est exécuté sur un ordinateur.
EP08806056A 2007-06-27 2008-06-23 Procede de gestion d'acces Withdrawn EP2163030A2 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0756083 2007-06-27
PCT/FR2008/051124 WO2009007578A2 (fr) 2007-06-27 2008-06-23 Procede de gestion d'acces

Publications (1)

Publication Number Publication Date
EP2163030A2 true EP2163030A2 (fr) 2010-03-17

Family

ID=38829578

Family Applications (1)

Application Number Title Priority Date Filing Date
EP08806056A Withdrawn EP2163030A2 (fr) 2007-06-27 2008-06-23 Procede de gestion d'acces

Country Status (3)

Country Link
US (1) US8752136B2 (fr)
EP (1) EP2163030A2 (fr)
WO (1) WO2009007578A2 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2023104305A1 (fr) * 2021-12-08 2023-06-15 Telefonaktiebolaget Lm Ericsson (Publ) Négociation de ressource de dispositif unique à multiple

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5787169A (en) * 1995-12-28 1998-07-28 International Business Machines Corp. Method and apparatus for controlling access to encrypted data files in a computer system
US6775668B1 (en) * 2000-09-11 2004-08-10 Novell, Inc. Method and system for enhancing quorum based access control to a database
US6959394B1 (en) * 2000-09-29 2005-10-25 Intel Corporation Splitting knowledge of a password
US8474028B2 (en) * 2006-10-06 2013-06-25 Fmr Llc Multi-party, secure multi-channel authentication

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
None *

Also Published As

Publication number Publication date
US8752136B2 (en) 2014-06-10
US20100180320A1 (en) 2010-07-15
WO2009007578A3 (fr) 2009-05-07
WO2009007578A2 (fr) 2009-01-15

Similar Documents

Publication Publication Date Title
EP2071798B1 (fr) Procédé et serveur de coffres-forts électroniques avec mutualisation d'informations
US9189615B2 (en) Systems and methods for system login and single sign-on
FR2989799A1 (fr) Procede de transfert d'un dispositif a un autre de droits d'acces a un service
EP2238558A1 (fr) Appareil, et méthodologie associée, pour faciliter une authentification à l'aide d'un jeton d'authentification de musique numérique
FR3048530B1 (fr) Systeme ouvert et securise de signature electronique et procede associe
EP2619941A1 (fr) Procede, serveur et systeme d'authentification d'une personne
EP3765984A1 (fr) Traitement sécurisé de données
EP3667530B1 (fr) Accès sécurise à des données chiffrées d'un terminal utilisateur
WO2009007578A2 (fr) Procede de gestion d'acces
EP2071799B1 (fr) Procédé et serveur pour l'accès a un coffre-fort électronique via plusieurs entités
FR2867577A1 (fr) Procede permettant de remplir automatiquement des donnees utilisateur en utilisant une identification d'empreintes digitales
EP2285042A1 (fr) Module logiciel de sécurisation utilisant le chiffrement du haché d'un mot de passe concaténé avec une graine
FR3031824A1 (fr) Procede de securisation de donnees par anonymisation et serveur associe
FR3022716A1 (fr) Procede de partage de fichiers numeriques entre plusieurs ordinateurs, et ordinateur, ensemble de stockage de donnees et systeme de partage de fichiers numeriques associes
FR2913551A1 (fr) Methode d'authentification mutuelle et recurrente sur internet.
EP3899765B1 (fr) Réinitialisation d'un secret applicatif au moyen du terminal
WO2024079144A1 (fr) Procédé de gestion de données d'authentification permettant l'accès à un service d'un utilisateur depuis un terminal
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
EP2755160B1 (fr) Procédé de traçage de données liées à l'activité d'un utilisateur d'un équipement
FR3114891A3 (fr) Système d’identification biométrique
FR3137769A1 (fr) Procédé de sauvegarde de données personnelles sensibles sur une chaîne de blocs
EP2413260A1 (fr) Téléphone mobile muni d'un système sécurisé d'identification
WO2017109352A1 (fr) Procede et dispositif de connexion a un serveur distant
FR3068801A1 (fr) Procede et systeme de gestion de licences de logiciel d'une entreprise fournissant des services a une entreprise cliente
FR3041196A1 (fr) Procede de gestion d'une liste d'au moins un mot de passe

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20100118

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MT NL NO PL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL BA MK RS

DAX Request for extension of the european patent (deleted)
RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: ORANGE

17Q First examination report despatched

Effective date: 20151030

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: GRANT OF PATENT IS INTENDED

RIC1 Information provided on ipc code assigned before grant

Ipc: G06F 21/31 20130101ALI20180209BHEP

Ipc: H04L 9/08 20060101AFI20180209BHEP

Ipc: G06F 21/30 20130101ALI20180209BHEP

Ipc: H04L 29/06 20060101ALI20180209BHEP

Ipc: H04L 9/32 20060101ALI20180209BHEP

Ipc: G06F 21/62 20130101ALI20180209BHEP

INTG Intention to grant announced

Effective date: 20180306

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20180717

RIC1 Information provided on ipc code assigned before grant

Ipc: H04L 9/08 20060101AFI20180209BHEP

Ipc: H04L 9/32 20060101ALI20180209BHEP

Ipc: H04L 29/06 20060101ALI20180209BHEP

Ipc: G06F 21/62 20130101ALI20180209BHEP

Ipc: G06F 21/31 20130101ALI20180209BHEP

Ipc: G06F 21/30 20130101ALI20180209BHEP