FR3146219A1 - Procédé de délivrance d'une autorisation d'accès pour un individu et procédé de vérification - Google Patents

Procédé de délivrance d'une autorisation d'accès pour un individu et procédé de vérification Download PDF

Info

Publication number
FR3146219A1
FR3146219A1 FR2301862A FR2301862A FR3146219A1 FR 3146219 A1 FR3146219 A1 FR 3146219A1 FR 2301862 A FR2301862 A FR 2301862A FR 2301862 A FR2301862 A FR 2301862A FR 3146219 A1 FR3146219 A1 FR 3146219A1
Authority
FR
France
Prior art keywords
access authorization
individual
data
server
client device
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.)
Pending
Application number
FR2301862A
Other languages
English (en)
Inventor
Yann BOUAN
Paul Edmond BERTHIER
Stéphane CAUCHIE
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.)
Idakto SAS
Original Assignee
Idakto SAS
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 Idakto SAS filed Critical Idakto SAS
Priority to FR2301862A priority Critical patent/FR3146219A1/fr
Priority to EP24707069.1A priority patent/EP4674088A1/fr
Priority to PCT/EP2024/054930 priority patent/WO2024180049A1/fr
Publication of FR3146219A1 publication Critical patent/FR3146219A1/fr
Pending 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/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • 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/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/062—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
    • 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/102—Entity profiles
    • 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/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Computer And Data Communications (AREA)

Abstract

L'invention concerne un procédé de délivrance d'une donnée d'autorisation d'accès pour un individu ayant une clé publique et un attribut donné, mis en œuvre dans un serveur d'autorisation d'accès apte à communiquer avec un serveur d'identification et un dispositif client. Le serveur d'autorisation d'accès a une règle et une donnée cryptographique secrète, la donnée cryptographique secrète étant spécifique pour un groupe d'individus ayant un attribut conforme à la règle. Le procédé comprend notamment une étape d'obtention d'un attribut de l'individu, une étape de détermination d'une conformité de l'attribut de l'individu à la règle. Si l'attribut de l'individu est conforme à la règle alors le procédé comprend une étape de génération d'une donnée d'autorisation d'accès pour l'individu à partir de la donnée cryptographique secrète et de la clé publique de l'individu et une étape de délivrance de la donnée d'autorisation d'accès au dispositif client. L'invention concerne également un procédé de vérification d'une autorisation d'accès d'un individu. [figure 2]

Description

Procédé de délivrance d'une autorisation d'accès pour un individu et procédé de vérification
L'invention concerne un procédé et un dispositif de délivrance d'une donnée d'autorisation d'accès pour un individu et un procédé et un dispositif de vérification d'une autorisation d'accès d'un individu associés.
L'accès à des contenus, des services, des applications, des ressources ou des serveurs d'un fournisseur de services est très souvent contrôlé. En particulier, l'accès au fournisseur de services peut être autorisé pour une ou plusieurs catégories de personnes en fonction de caractéristiques propres à la personne ou en fonction de capacités de la personne. Autrement dit, si la personne possède une (ou plusieurs) caractéristique donnée ou une (ou plusieurs) capacité particulière, il dispose d'une autorisation d'accès. Dans le cas contraire, l'accès est refusé à la personne.
Le contrôle d'accès au fournisseur de services peut être réalisé de manière rudimentaire. Par exemple, avant d'entrer sur un site web spécifique, la personne doit simplement déclarer qu'elle est majeure, saisir une date de naissance ou cliquer sur un bouton du type "j'ai plus de 18 ans". Ce contrôle d'accès est donc soumis à une vérification qui est basée uniquement sur une déclaration de la personne. Ce contrôle est très souvent anonyme et peut être basé sur des informations erronées.
A l'inverse, le contrôle de l'accès au fournisseur de services peut être réalisé d'une manière très élaborée. Par exemple, avant de se connecter sur une site web d'un fournisseur de services, la personne doit s'enregistrer auprès de celui-ci et fournir ses informations personnelles telles que son nom, son prénom, son âge, son adresse et fournir des informations bancaires ou de carte d'identité. Il obtient alors un identifiant et un mot de passe permettant un accès ultérieur au site web du fournisseur de services. Dans ce cas, l'accès n'est pas anonyme et chaque connexion au site web peut être tracée.
Une autre solution consiste à utiliser une identité numérique. Cette dernière permet de réduire la divulgation d'informations d'identité de la personne et d'atteindre l'objectif de prouver que la personne possède une ou plusieurs caractéristiques propres ou des capacités particulières.
Toutefois, ces solutions ne sont pas satisfaisantes pour plusieurs raisons. Le contrôle d'accès à un fournisseur de services en fonction de caractéristiques propres à la personne est réalisé soit en fonction d'informations déclaratives pouvant être erronées soit suite à un enregistrement auprès de ce fournisseur de services avec la fourniture à ce dernier d'informations relatives à la personne. Ainsi, les solutions actuellement disponibles ne permettent pas un accès au fournisseur de services fiable au regard des caractéristiques de la personne, anonyme et non traçable.
Le but de l'invention est de remédier à ces inconvénients et de permettre d'une part la délivrance d'une donnée d'autorisation d'accès pour un individu en fonction d'au moins un de ses attributs par un serveur d'autorisation d'accès afin que ce dernier apporte ensuite la preuve à un fournisseur de services qu'il possède au moins un attribut qui satisfasse le fournisseur de services.
D'autre part, l'invention permet une vérification d'une autorisation d'accès d'un individu, la vérification étant réalisée de manière anonyme et sans traçabilité des différents accès.
Ainsi, l'invention a pour objet un procédé de délivrance d'une donnée d'autorisation d'accès pour un individu ayant une clé publique et au moins un attribut donné, le procédé étant mis en œuvre dans un serveur d'autorisation d'accès apte à communiquer avec un serveur d'identification et un dispositif client, le serveur d'autorisation d'accès ayant au moins une règle donnée et une donnée cryptographique secrète, la donnée cryptographique secrète étant spécifique pour un groupe d'individus ayant au moins un attribut conforme à ladite au moins une règle donnée. Le procédé comprenant les étapes suivantes :
  • obtention de la clé publique de l'individu ;
  • obtention dudit moins un attribut de l'individu provenant du serveur d'identification ;
  • détermination d'une conformité dudit au moins un attribut de l'individu obtenu à ladite au moins une règle donnée ;
  • si ledit au moins un attribut de l'individu est conforme à ladite au moins une règle donnée, génération d'une donnée d'autorisation d'accès pour l'individu à partir de la donnée cryptographique secrète et de la clé publique de l'individu obtenue ;
  • délivrance de la donnée d'autorisation d'accès générée au dispositif client.
Le procédé conforme à l'invention permet la délivrance d'une information d'autorisation d'accès à un individu si ce dernier possède un ou plusieurs attributs conformes à une ou plusieurs règles. L'information d'autorisation d'accès permettra ultérieurement à l'individu de prouver à un fournisseur de services qu'il possède un ou plusieurs attributs, de manière fiable et anonyme.
Le serveur d'autorisation d'accès peut comprendre en outre une donnée cryptographique publique associée à ladite donnée cryptographique secrète, le procédé peut comprendre alors en outre une étape de transmission de la donnée cryptographique publique au dispositif client.
Le procédé peut comprendre en outre une étape de vérification de la possession d'une clé privée de l'individu par le dispositif client associée à la clé publique de l'individu obtenue, préalablement à la délivrance de la donnée d'autorisation d'accès.
Le procédé peut comprendre en outre une étape d'obtention d'un identifiant de demande d'une donnée d'autorisation d'accès et une étape de transmission de l'identifiant de demande d'une donnée d'autorisation d'accès au serveur d'identification.
L'identifiant de demande d'une donnée d'autorisation d'accès peut dans ce cas comprendre un identifiant de l'individu.
Alternativement, le procédé peut comprendre en outre, une étape d'obtention d'un identifiant de l'individu provenant du serveur d'identification ou du dispositif client.
L'invention a également pour objet un procédé de vérification d'une autorisation d'accès d'un individu ayant une donnée d'autorisation d'accès, la donnée d'autorisation d'accès ayant été délivrée conformément au procédé décrit précédemment. Le procédé est mis en œuvre dans un serveur d'autorisation d'accès apte à communiquer avec un fournisseur de services, le fournisseur de services mettant en œuvre un contrôle d'accès en fonction d'au moins un attribut de l'individu. Le serveur d'autorisation d'accès a une donnée cryptographique publique, la donnée cryptographique publique étant spécifique pour un groupe d'individus ayant au moins un attribut conforme à au moins une règle donnée, ladite donnée cryptographique publique étant associée à une donnée cryptographique secrète, ladite donnée cryptographique secrète ayant été utilisée pour générer la donnée d'autorisation d'accès. Le procédé comprend les étapes suivantes :
  • réception d'une information de preuve d'autorisation d'accès, l'information de preuve d'autorisation d'accès ayant été générée au moyen de la donnée d'autorisation d'accès de l'individu ;
  • vérification de l'information de preuve d'autorisation d'accès reçue en utilisant la donnée cryptographique publique ;
  • si l'information de preuve d'autorisation d'accès est vérifiée, envoi au fournisseur de services d'une information de validation de l'information de preuve d'autorisation d'accès, sans vérification de la conformité d'au moins un attribut de l'individu à ladite au moins une règle donnée lors de la vérification de l'autorisation d'accès.
La donnée cryptographique publique peut être reçue du fournisseur de services ou d'un dispositif client.
L'information de preuve d'autorisation d'accès peut être reçue du fournisseur de services ou d'un dispositif client.
Le serveur d'autorisation d'accès peut en outre être apte à communiquer avec un dispositif client. Le procédé peut alors comprendre en outre, les étapes suivantes :
  • réception d'un identifiant de demande de vérification provenant du fournisseur de services ;
  • génération d'une information de connexion à partir de l'identifiant de demande de vérification reçu ;
  • transmission au fournisseur de services de l'information de connexion générée ;
  • création d'un canal de communication entre le serveur d'autorisation d'accès et le dispositif client au moyen de l'information de connexion ;
  • réception de l'information de preuve d'autorisation d'accès du dispositif client via le canal de communication créé.
Le serveur d'autorisation d'accès peut en outre être apte à communiquer avec un dispositif client. Le procédé peut alors comprendre en outre les étapes suivantes :
  • génération d'une donnée de vérification ;
  • transmission de la donnée de vérification générée au dispositif client ;
  • l'information de preuve d'autorisation d'accès reçue étant en outre générée à partir de la donnée de vérification.
Le serveur d'autorisation d'accès peut être apte à communiquer avec une base de données de preuves, et le procédé peut alors comprendre en outre, une étape de transmission à ladite base de données de preuves de l'information de preuve d'autorisation d'accès reçue.
Le serveur d'autorisation d'accès peut comprendre en outre une donnée identifiant le groupe d'individus ayant au moins un attribut conforme à ladite au moins une règle donnée, et l'étape d'envoi au fournisseur de services d'une information de validation de l'information de preuve d'autorisation d'accès peut alors comprendre en outre l'envoi de la donnée identifiant le groupe d'individus.
L'invention a également pour objet un dispositif configuré pour mettre en œuvre au moins l'un des procédés précédemment décrits.
On va maintenant décrire des exemples de réalisation de la présente invention en référence aux figures annexées où les mêmes références désignent d'une figure à l'autre des éléments identiques ou fonctionnellement semblables :
illustre un exemple d'un système dans lequel un procédé de délivrance d'une donnée d'autorisation d'accès pour un individu conformément à l'invention et un procédé de vérification d'une autorisation d'accès d'un individu conformément à l'invention peuvent être mis en œuvre.
illustre un mode de réalisation du procédé de délivrance d'une donnée d'autorisation d'accès pour un individu conformément à l'invention.
illustre un premier exemple de système dans lequel un serveur d'autorisation d'accès met en œuvre un mode de réalisation du procédé de délivrance d'une donnée d'autorisation d'accès pour un individu conformément à l'invention.
illustre un deuxième exemple de système dans lequel un serveur d'autorisation d'accès met en œuvre un autre mode de réalisation du procédé de délivrance d'une donnée d'autorisation d'accès pour un individu conformément à l'invention.
illustre un mode de réalisation du procédé de vérification d'une autorisation d'accès d'un individu conformément à l'invention.
illustre un premier exemple de système dans lequel un serveur d'autorisation d'accès met en œuvre un mode de réalisation du procédé de vérification d'une autorisation d'accès d'un individu conformément à l'invention.
illustre un deuxième exemple de système dans lequel un serveur d'autorisation d'accès met en œuvre un autre mode de réalisation du procédé de vérification d'une autorisation d'accès d'un individu conformément à l'invention.
illustre un premier exemple de système dans lequel un serveur de contrôle met en œuvre un mode de réalisation d'un procédé de détermination de l'identité de l'individu ayant demandé une vérification d'une autorisation d'accès.
illustre un deuxième exemple de système dans lequel un serveur de contrôle met en œuvre un mode de réalisation d'un procédé de détermination de l'identité de l'individu ayant demandé une vérification d'une autorisation d'accès.
La présente invention concerne selon un premier aspect, une manière sûre et fiable, de délivrer une donnée d'autorisation d'accès pour un individu ayant une clé publique et au moins un attribut donné permettant ultérieurement un accès anonyme et non-traçable de l'individu auprès d'un fournisseur de services disposant d'un contrôle d'accès en fonction d'attributs de l'individu.
Un contrôle d'accès en fonction d'un ou plusieurs attributs de l'individu autorise l'accès de l'individu uniquement si celui-ci est capable d'apporter la preuve qu'un ou plusieurs de ses attributs sont conformes à une ou plusieurs règles. Un tel contrôle d'accès permet de filtrer l'accès de l'individu à un contenu, des services, des applications, des ressources ou des serveurs d'un fournisseur de services. La délivrance d'une donnée d'autorisation d'accès est fonction d'au moins un attribut donné de l'individu.
La donnée d'autorisation d'accès est générée pour un individu de sorte à permettre ultérieurement à ce dernier un accès anonyme, donc sans avoir à divulguer son identité et ses attributs. La donnée d'autorisation d'accès a un rôle d'attestation numérique anonyme certifiant que l'individu a au moins un attribut conforme à une règle donnée. En particulier, l'invention concerne un procédé de délivrance d'une donnée d'autorisation d'accès pour un individu ayant une clé publique et au moins un attribut donné, mis en œuvre dans un serveur d'autorisation d'accès.
La présente invention concerne selon un deuxième aspect une manière sûre et fiable de réaliser une vérification d'autorisation d'accès d'un individu souhaitant accéder à un fournisseur de services mettant en œuvre un contrôle d'accès en fonction d'au moins un attribut de l'individu. La vérification est réalisée au moyen d'une information de preuve d'autorisation d'accès générée à partir de la donnée d'autorisation d'accès préalablement générée pour l'individu. Une telle vérification d'autorisation d'accès permet de s'assurer que l'individu a effectivement au moins un attribut conforme à au moins une règle donnée et donc qu'il est légitime pour accéder au fournisseur de services. Toutefois, la vérification est réalisée sans avoir à vérifier effectivement la conformité du ou des attributs de l'individu à une ou des règles données, la conformité ayant été réalisée précédemment par la délivrance de la donnée d'autorisation d'accès.
Ainsi, il est rendu possible de vérifier une autorisation d'accès d'un individu à un fournisseur de services au moyen d'une information de preuve d'autorisation d'accès générée à partir de la donnée d'autorisation d'accès de l'individu, de manière anonyme et sans pouvoir tracer les connexions de l'individu. En particulier, l'invention concerne un procédé de vérification d'une autorisation d'accès d'un individu ayant une donnée d'autorisation d'accès mis en œuvre dans un serveur d'autorisation d'accès.
Un attribut d'un individu est une caractéristique d'un individu, telle que son âge, sa région de domiciliation, son pays de domiciliation, etc., ou une capacité de l'individu, telle que la possession du permis de conduire ou d'un permis de travail. L'attribut peut également comprendre le fait pour un individu de disposer d'un compte d'accès auprès d'un organisme, tel qu'un organisme public, une banque, etc.
Conformément à l'invention, une donnée d'autorisation d'accès est délivrée à un individu, si un attribut de ce dernier est conforme à une règle donnée ou si des attributs de l'individu sont conformes respectivement à des règles données. Une règle a pour but de définir un critère d'accès. Par exemple, une règle relative à l'attribut "âge" peut être "avoir plus de 18 ans", une règle relative aux capacités de l'individu peut être "avoir un permis de conduire".
En référence à la , il est décrit un exemple d'un système dans lequel peut être mis en œuvre un procédé de délivrance d'une donnée d'autorisation d'accès pour un individu conformément à l'invention et un procédé de vérification d'une autorisation d'accès d'un individu conformément à l'invention.
Le système comprend un individu INDIV, au moins un dispositif client à la disposition de l'individu DEV, un serveur d'autorisation d'accès SERV-AUTO, un fournisseur de services FRS-SERV et un serveur d'identification IDP. Il peut comprendre en outre un support d'identité CAP de l'individu INDIV et un dispositif de contrôle CONTROL.
Un individu INDIV est un utilisateur qui souhaite accéder à un contenu, une application, un service, un serveur, etc. d'un fournisseur de services en utilisant un dispositif client DEV. Il a un identifiant IDu, au moins un attribut donné ATT, une clé publique pkuet une clé secrète skuassociée. Pour prouver qu'il possède l'attribut ou les attributs nécessaires à la connexion au fournisseur de services, il va tout d'abord obtenir une donnée d'autorisation d'accès qui peut être mémorisée dans un espace sécurisé du dispositif client. Ensuite, il va générer une information de preuve afin de prouver qu'il dispose d'une autorisation d'accès pour une connexion au fournisseur de services, sans toutefois divulguer à ce dernier son identité et ses attributs ATT. Autrement dit, il va générer une information de preuve qui devra être vérifiée permettant de certifier au fournisseur de services qu'il dispose du ou des attributs lui permettant une connexion à ce dernier sans toutefois que le fournisseur de services n'est accès à l'identité et aux attributs ATT de l'individu.
Le dispositif client DEV peut être tout type de dispositif, tel qu'un téléphone portable, une tablette, un ordinateur, etc., comprenant une plateforme matérielle et logicielle sur laquelle s'exécutent des logiciels, ces logiciels étant soit directement exécutables soit interprétés sur une machine virtuelle. Le dispositif client DEV comprend en particulier une interface de communication homme-machine permettant d'afficher des données et de recevoir des données provenant de l'individu INDIV. Cette interface de communication homme-machine comprend par exemple un écran et un clavier, ou un écran tactile. Le dispositif client DEV peut comprendre un navigateur Internet s'exécutant sur l'interface de communication homme-machine. Le dispositif client est apte à communiquer avec le serveur d'autorisation d'accès SERV-AUTO, le fournisseur de services FRS-SERV et le serveur d'identification IDP. Il peut aussi communiquer avec le support d'identité CAP. Pour cela, le dispositif client DEV est muni de moyens de communication (filaire ou sans fil). Par exemple, le dispositif client DEV peut comprendre une connectivité de type réseau, soit via une connexion filaire soit via une connexion sans fil (par exemple, conforme à la norme Bluetooth, à la norme NFC, à la norme WIFI ou à la norme PC/SC) pour une communication avec le support d'identité CAP et peut comprendre des moyens de communication réseau conformes à l'une quelconques des normes Ethernet, et/ou conformes à l'une quelconque des normes IEEE 802.11 (Wifi), et/ou conformes à une ou plusieurs normes de téléphonie mobile (2G, 3G, 4G, etc.) pour une communication avec le serveur d'autorisation d'accès SERV-AUTO, le fournisseur de services FRS-SERV et le serveur d'identification IDP.
Le support d'identité CAP est un moyen mémorisant des informations propres à l'individu INDIV. Il peut comprendre notamment un identifiant de l'individu IDu, le ou les attributs ATT de ce dernier et/ou une clé privée skuet une clé publique pkude l'individu. Il peut s'agir par exemple, d'une carte d'identité électronique, d'un passeport électronique ou d'une carte bancaire. Il comprend des moyens de connectivité, notamment des moyens de communication sans fil (par exemple, conforme à la norme Bluetooth, à la norme NFC ou à la norme PC/SC) afin d'être apte à communiquer avec un dispositif client DEV. Le support d'identité CAP peut comprendre en outre, une fonction d'établissement d'un canal de communication sécurisé permettant la création d'un canal de communication sécurisé entre le support d'identité CAP et le dispositif client DEV. L'établissement d'un canal de communication sécurisé s'appuie sur l'utilisation de protocoles de sécurité. Le dispositif client DEV peut également comprendre en outre, une fonction d'établissement d'un canal de communication sécurisé permettant la création d'un canal sécurisé entre le dispositif client DEV et le support d'identité CAP. L'établissement d'un canal de communication sécurisé s'appuie sur l'utilisation de protocoles de sécurité.
Selon un mode de réalisation dans lequel le système ne comprend pas de support d'identité CAP, l'identifiant de l'individu IDu, le ou les attributs ATT de ce dernier et/ou une clé privée skuet une clé publique pkude l'individu INDIV peuvent être mémorisés dans le dispositif client DEV, notamment dans un espace mémoire sécurisé.
Le serveur d'identification IDP comprend une plateforme matérielle et logicielle sur laquelle s'exécutent des logiciels. Il peut être utilisé pour authentifier un individu, notamment à partir de l'identifiant de ce dernier IDu, et il peut fournir, notamment au serveur d'autorisation d'accès, le ou les attributs ATT de l'individu INDIV dont il a eu régulièrement la connaissance. En particulier, le serveur d'identification IDP mémorise pour un ensemble d'individus, leur identifiant IDuet un ou plusieurs attributs ATT de ces individus. Un serveur d'identification IDP est, par exemple un fournisseur d'identité gouvernemental, une banque ou un espace sécurisé de données. Le serveur d'identification IDP peut comprendre une fonction d'établissement d'un canal de communication sécurisé permettant la création d'un canal sécurisé entre le serveur d'identification IDP et le dispositif client DEV ou entre le serveur d'identification IDP et le serveur d'autorisation d'accès SERV-AUTO. L'établissement d'un canal de communication sécurisé s'appuie sur l'utilisation de protocoles de sécurité La connexion au serveur d'identification IDP nécessite une authentification sévère. Pour cela, différentes technologies peuvent être utilisées telles que OpenID, SAML, ISO18013 ou ISO2020.
Le fournisseur de services FRS-SERV est par exemple un fournisseur de services d'applications ou un fournisseur d'applications en ligne. Autrement dit, il peut s'agir d'un fournisseur d'applications hébergées qui fournit des logiciels, des contenus ou des services informatiques à ses clients au travers d'un réseau Internet par exemple. L'accès à ces applications est notamment réalisé à travers un navigateur web et en utilisant un protocole standard comme le protocole http. Ainsi, le fournisseur de services FRS-SERV comprend une plateforme matérielle et logicielle sur laquelle s'exécutent des applications afin de fournir des logiciels, des services ou des contenus. Selon le cas, le fournisseur de services peut vouloir ou a une obligation de s'assurer que l'individu qui souhaite accéder à ces services, applications ou contenus appartienne à une certaine catégorie de personnes, par exemple que l'individu soit majeur. En d'autres termes, dans ce cas, le fournisseur de services met en œuvre un contrôle d'accès en fonction d'au moins un attribut de l'individu. Pour ce faire, le fournisseur de services communique avec le serveur d'autorisation d'accès SERV-AUTO.
Le serveur d'autorisation d'accès SERV-AUTO fournit un service qui délivre une donnée d'autorisation d'accès à un individu et qui vérifie une autorisation d'accès d'un individu pour prouver la légitimité d'un individu à accéder à un service, un contenu, une application, etc. d'un fournisseur de services. Le serveur d'autorisation d'accès est apte à mettre en œuvre tout ou partie du procédé de délivrance d'une donnée d'autorisation d'accès pour un individu ou du procédé de vérification d'une autorisation d'accès d'un individu conformément à l'invention. Tout ou partie du procédé de délivrance d'une donnée d'autorisation d'accès pour un individu et/ou tout ou partie du procédé de vérification d'une autorisation d'accès d'un individu peuvent être mis en œuvre sous forme logicielle et/ou sous forme de dispositif(s). Les modes de réalisation du serveur d'autorisation d'accès SERV-AUTO décrits ci-après sont tels que le serveur d'autorisation d'accès SERV-AUTO est apte à mettre en œuvre tout ou partie du précédé de délivrance d'une information d'autorisation d'accès pour un individu et du procédé de vérification d'une autorisation d'accès d'un individu. Cependant, selon d'autres modes de réalisation, le procédé de délivrance d'une donnée d'autorisation d'accès pour un individu et le procédé de vérification d'une autorisation d'accès d'un individu peuvent être mis en œuvre dans des serveurs distincts.
Le serveur d'autorisation d'accès SERV-AUTO est apte à communiquer avec le fournisseur de services FRS-SERV et le serveur d'identification IDP en utilisant des moyens de connectivité dont est pourvu le serveur d'autorisation d'accès SERV-AUTO. Les moyens de connectivité du serveur d'autorisation d'accès SERV-AUTO peuvent comprendre des moyens des communication réseau conformes à l'une quelconques des normes Ethernet, et/ou conformes à l'une quelconque des normes IEEE 802.11 (Wifi), et/ou conformes à une ou plusieurs normes de téléphonie mobile (2G, 3G, 4G, etc.). Il peut en outre communiquer avec le dispositif client DEV et le serveur de contrôle CONTROL.
Le serveur d'autorisation d'accès SERV-AUTO comprend en outre, des moyens d'exécution d'un algorithme de calcul et d'échange de clés cryptographiques.
Un serveur de contrôle CONTROL peut être mis en œuvre pour révéler l'identité de l'individu qui a soumis une information de preuve d'autorisation d'accès au fournisseur de services. Toutefois, ce serveur est mis en œuvre notamment dans les modes de réalisation dans lesquels il est nécessaire de pouvoir retrouver l'identité de l'individu ayant soumis une information de preuve d'autorisation d'accès au fournisseur de services.
La illustre un mode de réalisation du procédé de délivrance d'une donnée d'autorisation d'accès pour un individu INDIV ayant une clé publique pkuet au moins un attribut donné ATT conformément à l'invention. Les étapes en pointillées sur la figure sont optionnelles.
Le procédé est mis en œuvre dans un serveur d'autorisation d'accès SERV-AUTO apte à communiquer avec un serveur d'identification IDP et un dispositif client DEV.
Le serveur d'autorisation d'accès SERV-AUTO comprend au moins une règle donnée. Il comprend en outre une paire de données cryptographiques spécifiques pour un groupe d'individus ayant au moins un attribut conforme à ladite au moins une règle donnée. La paire de données cryptographiques comprend une donnée cryptographique secrète et une donnée cryptographique publique. Un groupe d'individus comprend un ensemble d'individus ayant obtenu une information d'autorisation d'accès car le ou les attributs de ces individus sont conformes à ladite au moins une règle donnée.
Le procédé peut débuter par une étape d'obtention d'un identifiant de demande d'une donnée d'autorisation d'accès (étape 210). Cette étape peut résulter de la génération de l'identifiant de la demande par le dispositif client DEV et le service d'autorisation d'accès SERV-AUTO.
L'identifiant de demande d'une donnée d'autorisation d'accès est par exemple un identifiant de session établi entre le dispositif client et le serveur d'autorisation d'accès ou un code d'authentification.
Selon un mode de réalisation, l'identifiant de demande d'une donnée d'autorisation d'accès est obtenu par la génération d'un identifiant par le dispositif client et le serveur d'autorisation d'accès suite, par exemple, à l'échange de messages pour la création d'un canal de communication.
Selon un mode de réalisation particulier, l'identifiant de demande d'une donnée d'autorisation d'accès peut comprendre un identifiant de l'individu IDu.
L'identifiant de l'individu IDuest par exemple un identifiant personnel de cet individu. Il peut s'agir d'un identifiant attribué par un organisme spécifique (par exemple, un fournisseur d'identité gouvernemental, une banque, etc.). Ainsi, l'identifiant de l'individu IDupeut être un numéro d'identification ou des données personnelles comme un nom, un numéro de téléphone et/ou une date de naissance.
L'étape 210 est suivie d'une étape d'obtention de la clé publique de l'individu pku(étape 220). Selon un mode de réalisation particulier, l'étape 220 peut également comprendre l'obtention d'un identifiant de l'individu IDuassocié à la clé publique de l'individu pku.
L'étape 220 peut être suivie d'une étape 230 de transmission de l'identifiant de demande d'une donnée d'autorisation d'accès au serveur d'identification IDP (étape optionnelle) Cette étape peut permettre au serveur d'identification IDP d'initier un processus d'authentification avec l'individu notamment au moyen du dispositif client DEV (via ou non le serveur d'autorisation d'accès).
Le procédé se poursuit par une étape 240 d'obtention d'au moins un attribut ATT de l'individu INDIV. L'étape 240 d'obtention d'au moins un attribut ATT est réalisée par la réception dudit au moins un attribut de l'individu INDIV transmis directement ou indirectement par le serveur d'identification IDP au serveur d'autorisation d'accès SERV-AUTO. Le ou les attributs d'un individu sont déterminées par le serveur d'identification IDP par exemple après l'authentification de l'individu auprès du serveur d'identification IDP ou à partir de l'identifiant de l'individu IDu.
Selon un mode de réalisation particulier, le procédé peut également comprendre une étape d'obtention d'un identifiant de l'individu IDuprovenant du serveur d'identification IDP, notamment dans le cas où l'identifiant de l'individu IDun'a pas été transmis par le dispositif client. L'identifiant de l'individu IDuest alors associée à la clé publique de l'individu reçue.
L'étape 240 est suivie d'une étape 250 de détermination d'une conformité dudit au moins un attribut ATT de l'individu obtenu à ladite au moins une règle donnée du serveur d'autorisation d'accès.
Selon un exemple particulier, l'attribut de l'individu comprend la donnée selon laquelle l'individu est en possession d'un permis de conduire et la règle définit un critère relatif à la possession du permis de conduire. Dans le présent exemple, l'attribut de l'individu est conforme à la règle puisque l'attribut est conforme au critère.
L'étape 250 est suivie d'une étape 260 de test relatif à la conformité dudit au moins un attribut ATT de l'individu à ladite au moins une règle donnée. Si le test est négatif, l'étape 260 est suivie d'une étape 270 de fin du procédé et aucune donnée d'autorisation d'accès n'est générée et délivrée à l'individu. Si, au contraire, le test de l'étape 260 est positif, alors l'étape 260 est suivie d'une étape 280 de génération d'une donnée d'autorisation d'accès pour l'individu à partir de la donnée cryptographique secrète et de la clé publique de l'individu pkuobtenue.
Dans le mode de réalisation dans lequel le serveur d'autorisation d'accès a obtenu l'identifiant de l'individu IDu, la donnée d'autorisation d'accès pour l'individu est en outre générée à partir de l'identifiant de l'individu IDu.
L'étape 280 est ensuite suivie d'une étape 290 de délivrance de la donnée d'autorisation d'accès générée au dispositif client DEV. Cette étape comprend par exemple l'envoi de la donnée d'autorisation d'accès générée au dispositif client.
Le procédé de délivrance peut en outre comprendre une étape de transmission de la donnée cryptographique publique au dispositif client DEV.
Selon un mode de réalisation, préalablement à l'étape de délivrance de la donnée d'autorisation d'accès générée, le procédé peut comprendre en outre une étape de vérification de la possession de la clé privée skupar l'individu, en particulier par le dispositif client de l'individu, associée à la clé publique de l'individu pkuobtenue et utilisée pour la génération de la donnée d'autorisation d'accès. Cette étape permet au serveur d'autorisation d'accès de s'assurer que la donnée d'autorisation d'accès générée est délivrée à l'individu possédant la clé publique utilisée pour la génération de la donnée d'autorisation d'accès.
Selon un mode de réalisation particulier dans lequel le serveur d'autorisation d'accès a obtenu l'identifiant de l'individu IDu, le procédé comprend en outre une étape de mémorisation dans une base de données d'individus BD-INDIV, de l'identifiant de l'individu IDuet de la clé publique pkude cet individu. La base de données d'individus peut être mémorisées sur un serveur distinct du serveur d'autorisation d'accès.
Selon un autre mode de réalisation particulier du procédé de délivrance d'une donnée d'autorisation d'accès pour un individu, l'identifiant de l'individu IDun'est pas fourni au serveur d'autorisation d'accès.
La illustre un premier exemple d'un système comprenant un serveur d'autorisation d'accès SERV-AUTO lequel met en œuvre un mode de réalisation particulier du procédé de délivrance d'une donnée d'autorisation d'accès pour un individu ayant une clé publique pkuet au moins un attribut donné ATT conformément à l'invention.
Le système illustré en comprend en plus du serveur d'autorisation d'accès SERV-AUTO, un dispositif client DEV et un serveur d'identification IDP.
Le serveur d'autorisation d'accès SERV-AUTO comprend au moins une règle donnée. Il comprend en outre une paire de données cryptographiques spécifiques pour un groupe d'individus ayant au moins un attribut conforme à ladite au moins une règle donnée. La paire de données cryptographiques comprend une donnée cryptographique secrète et une donnée cryptographique publique. Un groupe d'individus comprend un ensemble d'individus ayant obtenu une information d'autorisation d'accès car le ou les attributs de ces individus sont conformes à ladite au moins une règle donnée.
Le dispositif client DEV est par exemple un téléphone portable. L'individu INDIV peut en outre être muni d'un support d'identité CAP comprenant notamment la clé publique pkude l'individu. Le support d'identité CAP peut également comprendre un identifiant de l'individu IDuassocié à la clé publique pkude l'individu. Le dispositif client DEV comprend des moyens de communication avec le support d'identité CAP.
Selon un autre mode de réalisation, la clé publique pkude l'individu peut être mémorisée sur le dispositif client DEV.
Selon le système illustré, le serveur d'autorisation d'accès obtient un identifiant de demande d'une donnée d'autorisation d'accès (étape 310). Cette étape peut comprendre l'échange de messages entre le serveur d'autorisation d'accès SERV-AUTO et le dispositif client DEV permettant la génération et l'obtention d'un identifiant de demande d'une donnée d'autorisation d'accès. Cette étape aboutit à l'obtention par le serveur d'autorisation d'accès SERV-AUTO d'un identifiant de demande d'une donnée d'autorisation d'accès conformément à l'étape 210 précédemment décrite au support de la .
Selon un mode de réalisation particulier, l'identifiant de demande d'une donnée d'autorisation d'accès comprend en outre un identifiant de l'individu IDu.
Lors de l'étape 310, le serveur d'autorisation d'accès SERV-AUTO obtient la clé publique de l'individu pku(conformément à l'étape 220 décrite précédemment au support de la ). En particulier, le dispositif client peut envoyer la clé publique de l'individu pkuau serveur d'autorisation d'accès SERV-AUTO.
Selon un mode de réalisation particulier, lors de l'étape 310, le serveur d'autorisation d'accès SERV-AUTO peut également obtenir l'identifiant de l'individu IDu.
L'étape 310 peut être suivie d'une étape de transmission par le serveur d'autorisation d'accès SERV-AUTO de l'identifiant de demande d'une donnée d'autorisation d'accès au serveur d'identification IDP (étape 320 qui conforme à l'étape 210 précédemment décrite au support de la ).
Selon un autre mode de réalisation, l'étape 320 est une étape de création d'un canal de communication sécurisé entre le serveur d'autorisation d'accès SERV-AUTO et le serveur d'identification IDP.
Selon le mode de réalisation illustré, l'étape 320 est suivie d'une phase d'authentification par l'individu auprès du serveur d'identification IDP, par exemple au moyen du dispositif client.
Pour cela, selon un premier mode de réalisation illustré à la , le serveur d'identification IDP communique avec le dispositif client DEV afin que l'individu s'authentifie (étape 330). Cela est possible notamment lorsque l'identifiant de demande d'une donnée d'autorisation d'accès reçu par le serveur d'identification IDP comprend l'identifiant de l'individu IDu.
Selon un autre mode de réalisation, l'authentification de l'individu peut être réalisée via le serveur d'autorisation d'accès, ce dernier ayant alors un rôle de proxy.
Selon encore un autre mode de réalisation, l'individu s'authentifie auprès du serveur d'identification IDP au moyen de son dispositif client DEV préalablement à l'étape 310 puis le dispositif client transmet au serveur d'autorisation d'accès, l'identifiant de l'individu IDuauthentifié.
Suite à l'authentification de l'individu auprès du serveur d'identification IDP, ce dernier transmet au serveur d'autorisation d'accès SERV-AUTO au moins un attribut ATT de l'individu (étape 340). Ainsi, le service d'autorisation d'accès SERV-AUTO obtient au moins un attribut ATT de l'individu provenant du serveur d'identification IDP conformément à l'étape 240 précédemment décrite au support de la .
Selon un mode de réalisation particulier, le serveur d'identification IDP transmet au serveur d'autorisation d'accès SERV-AUTO au moins un attribut ATT de l'individu via le dispositif client DEV.
Selon un mode de réalisation particulier, le serveur d'autorisation d'accès peut en outre obtenir du serveur d'identification un identifiant de l'individu IDu.
L'étape 340 est suivie d'une étape 350 au cours de laquelle le serveur d'autorisation d'accès SERV-AUTO va déterminer la conformité dudit au moins un attribut ATT de l'individu obtenu à ladite au moins une règle donnée conformément à l'étape 250 décrit au support de la . Si ledit au moins un attribut ATT de l'individu est conforme à ladite au moins une règle donnée, le serveur d'autorisation d'accès SERV-AUTO génère une donnée d'autorisation d'accès pour l'individu à partir de la donnée cryptographique secrète et de la clé publique de l'individu pkuobtenue, conformément aux étapes 260 et 280 précédemment décrites au support de la .
Dans le mode de réalisation dans lequel le serveur d'autorisation d'accès a obtenu l'identifiant de l'individu IDu, la donnée d'autorisation d'accès pour l'individu est en outre générée à partir de l'identifiant de l'individu IDu.
L'étape 350 est suivie d'une étape 360 de délivrance par le serveur d'autorisation d'accès SERV-AUTO de la donnée d'autorisation d'accès générée au dispositif client DEV conformément à l'étape 290 précédemment décrite au support de la . Pour cela, le serveur d'autorisation d'accès SERV-AUTO envoie un message au dispositif client DEV contenant la donnée d'autorisation d'accès générée.
Selon un mode de réalisation particulier, l'étape de délivrance de la donnée d'autorisation d'accès est précédée d'une étape de vérification de la possession de la clé privée skupar l'individu, en particulier par le dispositif client de l'individu, associée à la clé publique de l'individu pkuobtenue. Cette étape permet au serveur d'autorisation d'accès de vérifier avant de communiquer la donnée d'autorisation d'accès au dispositif client, que ce dernier dispose de la clé secrète de l'individu.
Dans le mode de réalisation particulier dans lequel le serveur d'autorisation d'accès a obtenu l'identifiant de l'individu IDu, le serveur d'autorisation d'accès peut comprendre en outre une étape de mémorisation dans une base de données d'individus BD-INDIV, de l'identifiant de l'individu IDuet de la clé publique de cet individu pku. D'autres informations additionnelles relatives à l'individu peuvent également être mémorisées dans la base de données d'individus BD-INDIV. La base de données d'individus BD-INDIV peut être mémorisée sur un serveur distinct du serveur d'autorisation d'accès.
La illustre un deuxième exemple d'un système comprenant un serveur d'autorisation d'accès SERV-AUTO lequel met en œuvre un autre mode de réalisation du procédé de délivrance d'une donnée d'autorisation d'accès pour un individu conformément à l'invention et décrit au support de la .
On ne décrira en détail ci-après que les étapes qui diffèrent de celles du premier exemple de système décrit au support de la . Pour le reste, il est renvoyé au premier exemple décrit au support de la .
Le serveur d'autorisation d'accès comprend au moins une règle donnée.
Dans cet exemple de système, l'individu comprend une paire de clés, à savoir une clé privée skuet une clé publique pkumémorisées par exemple sur un dispositif client DEV ou dans un support d'identité CAP et le serveur de contrôle CONTROL comprend une clé de divulgation secrète skoet une clé de divulgation publique pko.
La clé de divulgation publique pkodu serveur de contrôle CONTROL est transmise au serveur d'autorisation d'accès SERV-AUTO (étape 400).
Suite à la réception de la clé de divulgation publique pkoprovenant du serveur de contrôle CONTROL, le serveur d'autorisation d'accès SERV-AUTO va générer une paire de données cryptographique spécifique pour un groupe d'individus ayant au moins un attribut conforme à ladite au moins une règle donnée. La paire de données cryptographique comprend une donnée cryptographique publique Gpk et une donnée cryptographique secrète skm.
Dans l'exemple de réalisation illustré en , la donnée cryptographique publique Gpk comprend au moins une clé maitre publique pkmet la clé de divulgation publique pkoreçue du serveur de contrôle CONTROL.
Selon un autre mode de réalisation dans lequel le système ne comprend pas de serveur de contrôle CONTROL, le serveur d'autorisation d'accès comprend une paire de données cryptographique spécifique pour un groupe d'individus ayant au moins un attribut conforme à ladite au moins une règle donnée. La paire de données cryptographique comprend d'une part, une donnée cryptographique publique Gpk composée d'une clé maitre publique pkmet d'autre part, une donnée cryptographique secrète skm.
La donnée cryptographique publique Gpk peut ensuite être transmise au dispositif client DEV.
Selon le système illustré, le serveur d'autorisation d'accès obtient un identifiant de demande d'une donnée d'autorisation d'accès (étape 410) conformément à l'étape 210 précédemment décrite au support de la .
Selon un mode de réalisation particulier, l'identifiant de demande d'une donnée d'autorisation d'accès (étape 410) peut être déterminé par le dispositif client à partir notamment de la clé secrète skude l'individu et de la donnée cryptographique publique Gpk reçue. Il peut en outre être déterminé à partir de l'identifiant de l'individu IDu. L'identifiant de demande d'une donnée d'autorisation d'accès est ensuite transmis par le dispositif client et reçu par le serveur d'autorisation d'accès.
Lors de l'étape 410, le serveur d'autorisation d'accès SERV-AUTO obtient la clé publique de l'individu pku(conformément à l'étape 220 décrite précédemment au support de la ). En particulier, le dispositif client peut envoyer la clé publique de l'individu pkuau serveur d'autorisation d'accès SERV-AUTO.
L'étape 410 est ensuite suivie des étapes 320 à 340 précédemment décrites.
A l'issue de l'étape 340, le serveur d'autorisation d'accès SERV-AUTO va déterminer la conformité dudit au moins un attribut ATT de l'individu obtenu à ladite au moins une règle donnée conformément à l'étape 240 décrite précédemment au support de la . Si ledit au moins un attribut ATT de l'individu est conforme à ladite au moins une règle donnée, le serveur d'autorisation d'accès SERV-AUTO génère une donnée d'autorisation d'accès pour l'individu gskuà partir de la donnée cryptographique secrète skmet de la clé publique de l'individu pkuobtenue, conformément aux étapes 260 et 280 précédemment décrites au support de la .
L'étape 450 est suivie d'une étape 460.a de délivrance de la donnée d'autorisation d'accès gskugénérée, au dispositif client DEV.
Dans le mode de réalisation dans lequel le serveur d'autorisation d'accès a reçu l'identifiant de l'individu IDul'étape 450 peut également être suivie d'une étape 460.b de mémorisation par le serveur d'autorisation d'accès, dans une base de données d'individus BD-INDIV de l'identifiant de l'individu IDuet de la clé d'individu publique pkude cet individu. D'autres informations additionnelles relatives à l'individu peuvent également être mémorisées dans la base de données d'individus BD-INDIV. La base de données d'individus BD-INDIV peut être stockée sur un serveur distinct du serveur d'autorisation d'accès.
La illustre un mode de réalisation d'un procédé de vérification d'une autorisation d'accès d'un individu ayant une donnée d'autorisation d'accès mis en œuvre dans un serveur d'autorisation d'accès SERV-AUTO conformément à l'invention. La donnée d'autorisation d'accès a été délivrée conformément au procédé de délivrance d'une donnée d'autorisation d'accès précédemment décrit.
Le serveur d'autorisation d'accès SERV-AUTO est apte à communiquer avec un fournisseur de services FRS-SERV mettant en œuvre un contrôle d'accès en fonction d'au moins un attribut de l'individu.
Le serveur d'autorisation d'accès SERV-AUTO comprend une donnée cryptographique publique, la donnée cryptographique publique étant spécifique pour un groupe d'individus ayant au moins un attribut conforme à au moins une règle donnée. La donnée cryptographique publique est associée à une donnée cryptographique secrète, ladite donnée cryptographique secrète ayant été utilisée pour générer la donnée d'autorisation d'accès de l'individu.
Selon un mode de réalisation particulier, la donnée cryptographique publique peut être reçue par le serveur d'autorisation d'accès et provenir du fournisseur de services FRS-SERV. Selon un autre mode de réalisation dans lequel le serveur d'autorisation d'accès SERV-AUTO est apte à communiquer avec un dispositif client DEV de l'individu, la donnée cryptographique publique peut être reçue par le serveur d'autorisation d'accès et provenir du dispositif client DEV.
Le serveur d'autorisation d'accès SERV-AUTO mettant en œuvre le procédé de vérification d'une autorisation d'accès peut être le même serveur que celui mettant en œuvre le procédé de délivrance d'une information d'autorisation d'accès ou un serveur distinct.
Le procédé de vérification d'une autorisation d'accès peut faire suite au procédé de délivrance d'une donnée d'autorisation d'accès précédemment décrit au support de la et des figures suivantes.
L'objet du procédé de vérification d'une autorisation d'accès est de vérifier que l'individu dispose de l'autorisation d'accès pour accéder à un fournisseur de services mettant en œuvre un contrôle d'accès en fonction d'au moins un attribut de l'individu, sans vérification de la conformité du ou des attributs de l'individu à une ou plusieurs règles données lors de la vérification de l'autorisation d'accès. En outre, la vérification n'utilise pas non plus, un identifiant de l'individu.
Ainsi, ce procédé permet un contrôle d'accès d'un individu à un fournisseur de services mettant en œuvre un contrôle d'accès en fonction d'au moins un attribut de l'individu tout en garantissant un accès anonyme et non traçable de l'individu.
La non-traçabilité consiste à ne pas pouvoir identifier les différents accès d'un même individu au fournisseur de services. En d'autres termes, le système et le fournisseur de services ne peuvent pas déterminer si deux accès distincts appartiennent à un même individu (ou non).
Selon ce procédé, l'individu doit apporter une preuve qu'un ou plusieurs de ses attributs sont conformes à une ou plusieurs règles, les règles définissant les critères du contrôle d'accès du fournisseur de services. Pour cela, la preuve est une information de preuve d'autorisation d'accès générée par le dispositif client au moyen de la donnée d'autorisation d'accès qui lui a été précédemment délivrée.
En outre, selon le procédé de vérification conforme à l'invention, le ou les attributs ATT de l'individu ne sont pas communiquées au fournisseur de services. Toutefois, si l'information de preuve d'autorisation d'accès est validée par le procédé de vérification, le fournisseur de services mettant en œuvre un contrôle d'accès en fonction d'au moins un attribut de l'individu sait uniquement que la ou les règles relatives à un ou plusieurs attributs ATT de l'individu sont respectées.
Tel qu'illustré à la , le procédé de vérification d'une autorisation d'accès d'un individu ayant une donnée d'autorisation d'accès débute par une étape de réception d'une information de preuve d'autorisation d'accès (étape 510). L'information de preuve d'autorisation d'accès a été générée au moyen de la donnée d'autorisation d'accès de l'individu, notamment par le dispositif client de l'individu. L'information de preuve d'autorisation d'accès peut parvenir au serveur d'autorisation d'accès à partir du fournisseur de services ou du dispositif client de l'individu.
Cette étape peut être précédée d'une étape de génération d'une donnée de vérification c par le serveur d'autorisation d'accès, d'une étape de transmission de la donnée de vérification générée au dispositif client DEV. Dans ce cas, l'information de preuve d'autorisation d'accès reçue peut être en outre générée à partir de la donnée de vérification.
L'étape 510 est suivie d'une étape 520 de vérification de l'information de preuve d'autorisation d'accès reçue en utilisant la donnée cryptographique publique.
L'étape 520 est suivie d'une étape 530 de test de la vérification de l'information de preuve d'autorisation d'accès. Si l'information de preuve d'autorisation d'accès n'a pas pu être vérifiée, alors l'étape 530 est suivie de l'étape 540 au cours de laquelle le serveur d'autorisation d'accès peut indiquer au fournisseur de services que l'information de preuve d'autorisation d'accès est non valide.
Si, au contraire, l'information de preuve d'autorisation d'accès a pu être vérifiée, autrement dit l'information de preuve d'autorisation d'accès est valide, alors l'étape 530 est suivie d'une étape 550 d'envoi au fournisseur de services FRS-SERV d'une information de validation de l'information de preuve d'autorisation d'accès. Ainsi, lors de la vérification de l'autorisation d'accès, le serveur d'autorisation d'accès ne réalise pas de vérification de la conformité du ou des attributs de l'individu à une ou plusieurs règles données. En outre, le serveur d'autorisation d'accès n'utilise pas un identifiant de l'individu pour réaliser la vérification de l'autorisation d'accès.
Selon un mode de réalisation particulier, le serveur d'autorisation d'accès comprend en outre une donnée identifiant le groupe d'individus ayant au moins un attribut conforme à ladite au moins une règle donnée IdToken. Selon ce mode de réalisation l'étape d'envoi au fournisseur de services FRS-SERV d'une information de validation de l'information de preuve d'autorisation d'accès comprend en outre l'envoi de la donnée identifiant le groupe d'individus IdToken.
La illustre un premier exemple d'un système comprenant un serveur d'autorisation d'accès SERV-AUTO lequel met en œuvre un mode de réalisation particulier du procédé de vérification d'une autorisation d'accès d'un individu conformément à l'invention.
L'individu a une donnée d'autorisation d'accès précédemment délivrée conformément au procédé de délivrance d'une donnée d'autorisation d'accès décrit notamment au support de la .
Le serveur d'autorisation d'accès SERV-AUTO comprend une donnée cryptographique publique, la donnée cryptographique publique étant spécifique pour un groupe d'individus ayant au moins un attribut conforme à au moins une règle donnée. La donnée cryptographique publique est associée à une donnée cryptographique secrète, ladite donnée cryptographique secrète spécifique ayant été utilisée pour générer la donnée d'autorisation d'accès de l'individu.
Selon un mode de réalisation particulier, la donnée cryptographique publique est mémorisée dans le serveur d'autorisation d'accès. Selon un autre mode de réalisation, la donnée cryptographique publique est reçue par le serveur d'autorisation d'accès du fournisseur de services FRS-SERV. Selon encore un autre mode de réalisation, la donnée cryptographique publique est reçue par le serveur d'autorisation d'accès du dispositif client DEV.
Le système illustré en comprend en plus du serveur d'autorisation d'accès SERV-AUTO, un fournisseur de services FRS-SERV, un serveur d'identification IDP ou un serveur comprenant une base de données BD-PREUVES et un ou plusieurs dispositifs client DEV1, DEV2 d'un individu INDIV. La illustre un système particulier dans lequel l'individu INDIV dispose d'un premier dispositif client DEV1 et d'un second dispositif client DEV2 qui peuvent être par exemple un ordinateur portable et un téléphone portable. Dans le système illustré, la donnée d'autorisation d'accès de l'individu est par exemple mémorisée dans le second dispositif client DEV2. Toutefois, selon un autre mode de réalisation du système, le premier dispositif client DEV1 et le second dispositif client DEV2 sont un même dispositif client.
Lorsque l'individu INDIV souhaite accéder par exemple à un contenu, une application ou un service, etc. d'un fournisseur de services mettant en œuvre un contrôle d'accès en fonction d'au moins un attribut de l'individu, il peut utiliser un navigateur internet pour réaliser un tel accès (étape 610).
Le fournisseur de services doit alors vérifier que l'individu dispose d'un ou plusieurs attributs lui permettant l'accès. Pour ce faire, le fournisseur de services FRS-SERV peut communiquer, notamment de manière sécurisée au moyen d'un canal de communication sécurisé créé par exemple au moyen du protocole OpenID CIBA, avec le serveur d'autorisation d'accès SERV-AUTO afin de vérifier que l'individu dispose d'une autorisation d'accès au fournisseur de services (étape 620).
Un identifiant de demande de vérification SessionID est alors reçu par le serveur d'autorisation d'accès SERV-AUTO lors de l'étape 620. La réception de l'identifiant de demande de vérification peut être précédée d'une étape de génération de l'identifiant de demande de vérification par le fournisseur de services et le serveur d'autorisation d'accès.
Le serveur d'autorisation d'accès peut ensuite générer une information de connexion à partir de l'identifiant de demande de vérification reçu et transmettre l'information de connexion générée au fournisseur de services.
Selon le mode de réalisation illustré à la , le fournisseur de services transmet au dispositif client, par exemple au premier dispositif client DEV1, l'information de connexion qu'il a reçue (étape 630).
L'information de connexion peut être par exemple un QR Code qui va s'afficher sur l'écran d'affichage du premier dispositif client DEV1.
Selon un exemple de réalisation, l'individu scanne le QR Code s'affichant sur le premier dispositif client DEV1 au moyen du second dispositif client DEV2 (étape 640). Un canal de communication entre le serveur d'autorisation d'accès et le dispositif client, notamment le second dispositif client DEV2, est alors créé au moyen de l'information de connexion.
Le second dispositif client DEV2 génère ensuite une information de preuve d'autorisation d'accès, l'information de preuve d'autorisation d'accès étant générée au moyen de la donnée d'autorisation d'accès de l'individu mémorisée par exemple dans le second dispositif client DEV2.
Le serveur d'autorisation d'accès SERV-AUTO va alors recevoir l'information de preuve d'autorisation d'accès généré tel que précédemment décrit à l'étape 510 au support de la .
Le serveur d'autorisation d'accès reçoit l'information de preuve du second dispositif client de l'individu tel qu'illustré en (étape 650) via le canal de communication créé.
Selon un autre mode de réalisation dans lequel aucun canal de communication entre le serveur d'autorisation d'accès SERV-AUTO et le dispositif client DEV n'est créé, le dispositif client, par exemple le premier dispositif client DEV 1, peut transmettre l'information de preuve d'autorisation d'accès au serveur d'autorisation d'accès via le fournisseur de services. Dans ce mode de réalisation, l'information de preuve d'autorisation d'accès est générée sur l'un des dispositifs client DEV1 ou DEV2 au moyen de la donnée d'autorisation d'accès de l'individu mémorisée par exemple sur le second dispositif client DEV2.
Selon un mode de réalisation particulier, le serveur d'autorisation d'accès peut envoyer l'information de preuve d'autorisation d'accès reçue au serveur d'identification IDP ou à une base de données de preuves BD-PREUVES afin de mémoriser l'information de preuve d'autorisation d'accès reçue (étape 650.a). Outre l'information de preuve, le serveur d'autorisation d'accès peut également envoyer l'identifiant de demande de vérification SessionID et/ou la date et l'heure de la réception de l'information de preuve d'autorisation d'accès afin d'être mémorisées. Des donnés additionnelles utilisées par exemple pour la génération de l'information de preuve d'autorisation d'accès peuvent également être mémorisées dans la base de données de preuves.
Le serveur d'autorisation d'accès vérifie l'information de preuve d'autorisation d'accès reçue en utilisant la donnée cryptographique publique tel que précédemment décrit à l'étape 510.
Si l'information de preuve d'autorisation d'accès est vérifiée, alors le serveur d'autorisation d'accès envoie au fournisseur de services FRS-SERV une information de validation de l'information de preuve d'autorisation d'accès (étape 660) tel que précédemment décrit au regard de l'étape 530 de la . Lors de la vérification de l'autorisation d'accès de l'individu, le serveur d'autorisation d'accès ne vérifie pas la conformité du ou des attributs de l'individu à une ou plusieurs règles données. En outre, le serveur d'autorisation d'accès n'utilise pas l'identifiant de l'individu.
Selon un mode de réalisation particulier, le serveur d'autorisation d'accès comprend en outre une donnée identifiant le groupe d'individus ayant au moins un attribut conforme à ladite au moins une règle donnée IdToken. Selon ce mode de réalisation l'étape d'envoi au fournisseur de services FRS-SERV d'une information de validation de l'information de preuve d'autorisation d'accès comprend en outre l'envoi de la donnée identifiant le groupe d'individus IdToken.
Suite à la réception de l'information de validation de l'information de preuve d'autorisation d'accès par le fournisseur de services, celui-ci permet l'accès au fournisseur de services (étape 670).
Selon un mode de réalisation particulier, le serveur d'autorisation d'accès peut recevoir la donnée cryptographique publique du fournisseur de services FRS-SERV ou du dispositif client DEV afin de réaliser la vérification de l'information de preuve d'autorisation d'accès.
La illustre un deuxième exemple d'un système comprenant un serveur d'autorisation d'accès SERV-AUTO lequel met en œuvre un autre mode de réalisation du procédé de vérification d'une autorisation d'accès d'un individu ayant une donnée d'autorisation d'accès conformément à l'invention. La donnée d'autorisation d'accès gskude cet exemple a été générée selon le mode de réalisation du procédé de délivrance décrit au support de la .
On ne décrira en détail ci-après que les étapes qui diffèrent de celles du premier exemple de système décrit à la . Pour le reste, il est renvoyé au premier exemple décrit au support de la .
Dans cet exemple de réalisation, le serveur d'autorisation d'accès comprend une donnée cryptographique publique Gpk. La donnée cryptographique publique est spécifique pour un groupe d'individus ayant au moins un attribut conforme à au moins une règle donnée. La donnée cryptographique publique est associée à une donnée cryptographique secrète skm. Ladite donnée cryptographique secrète a été utilisée pour générer la donnée d'autorisation d'accès tel que décrit dans le mode de réalisation illustré à la .
La donnée cryptographique publique Gpk comprend au moins une clé maitre publique pkm. La donnée cryptographique publique Gpk peut en outre comprendre une clé de divulgation publique pko.
Selon un mode de réalisation particulier, la donnée cryptographique publique est mémorisée dans le serveur d'autorisation d'accès. Selon un autre mode de réalisation, la donnée cryptographique publique est reçue par le serveur d'autorisation d'accès du fournisseur de services FRS-SERV. Selon encore un autre mode de réalisation, la donnée cryptographique publique est reçue par le serveur d'autorisation d'accès du dispositif client DEV.
Tel qu'illustré à la , l'information de preuve d'autorisation d'accès σ est générée par le dispositif client au moyen d'un algorithme de signature ayant pour paramètre la donnée d'autorisation d'accès gskuet une donnée de vérification c à signer générée par le serveur d'autorisation d'accès et transmise au dispositif client. La donnée de vérification est par exemple un nombre aléatoire ou semi-aléatoire.
Dans le mode de réalisation illustré, l'information de preuve d'autorisation d'accès est générée sur l'un des dispositifs client DEV1 ou DEV2 au moyen de la donnée d'autorisation d'accès gskul'individu mémorisée par exemple sur le second dispositif client DEV2.
L'information de preuve d'autorisation d'accès est ensuite vérifiée par le serveur d'autorisation d'accès au moyen d'un algorithme de vérification de signature ayant comme paramètres, l'information de preuve d'autorisation d'accès σ, la donnée de vérification c et la donnée cryptographique publique Gpk (étape 750).
Selon un mode de réalisation particulier, le serveur d'autorisation d'accès peut envoyer l'information de preuve d'autorisation d'accès σ reçue au serveur d'identification IDP ou à une base de données de preuves BD-PREUVES afin de mémoriser l'information de preuve d'autorisation d'accès σ reçue (étape 750.a). Outre l'information de preuve, le serveur d'autorisation d'accès peut également envoyer l'identifiant de demande de vérification SessionID, la date et l'heure de la réception de l'information de preuve d'autorisation d'accès σ afin d'être mémorisées. Des donnés additionnelles utilisées par exemple pour la génération de l'information de preuve d'autorisation d'accès peuvent également être mémorisées dans la base de données de preuves, tel que la donnée de vérification c.
Il est illustré à la un premier exemple de système dans lequel un serveur de contrôle CONTROL détermine l'identité de l'individu ayant demandé une vérification d'une autorisation d'accès.
Le serveur de contrôle CONTROL peut en effet mettre en œuvre un procédé de détermination de l'identifiant d'un individu à partir d'une information de preuve d'autorisation d'accès fournie au fournisseur de services et mémorisée dans une base de données de preuves BD-PREUVES. La base de données de preuves BD-PREUVES mémorise les différentes informations de preuve d'autorisation d'accès soumises par les individus au fournisseur de services pour montrer qu'ils sont légitimes à accéder au fournisseur de services. En outre pour chaque information de preuve σ mémorisée, sont associées l'identifiant de demande de vérification SessionID et la donnée de vérification c. La date et l'heure de la réception de l'information de preuve d'autorisation d'accès par le serveur d'autorisation d'accès peuvent également être mémorisées pour chaque information de preuve mémorisée.
La base de données de preuves BD-PREUVES peut être mémorisée sur le serveur d'identification IDP.
Le système comprend en outre une base de données d'individus BD-INDIV mémorisant l'identifiant IDudes individus ayant demandé une donnée d'autorisation d'accès auprès du serveur d'autorisation d'accès. A chaque identifiant d'un individu est associée la clé publique pkude ce dernier.
Le procédé de détermination de l'identifiant d'un individu mis en œuvre dans le serveur de contrôle CONTROL a pour objectif de lever l'anonymat de l'individu ayant demandé une vérification d'une autorisation d'accès.
Le procédé de détermination de l'identifiant d'un individu débute par une étape de réception d'une demande de détermination de l'identifiant d'un individu (étape 810) et une étape de réception d'un identifiant de demande de vérification SessionID provenant du fournisseur de services FRS-SERV (étape 820). L'identifiant de demande de vérification SessionID identifie une session intervenue entre le fournisseur de services FRS-SERV et le serveur d'autorisation d'accès SERV-AUTO afin que ce dernier vérifie une information de preuve d'autorisation d'accès d'un individu.
A partir de l'identifiant de demande de vérification SessionID, le serveur de contrôle effectue une recherche dans la base de données de preuves BD-PREUVES afin d'identifier l'information de preuve d'autorisation d'accès σ mémorisée et la donnée de vérification c associées (étape 830).
L'étape 830 est suivie d'une étape 840 de détermination de l'identifiant de l'individu à partir de l'information de preuve d'autorisation d'accès σ et de la donnée de vérification c. Pour cela, le serveur de contrôle détermine tout d'abord la clé publique de l'individu pku. Ensuite, à partir de la clé publique déterminée pku, le serveur de contrôle effectue une recherche dans la base de données d'individus BD-INDIV de l'identifiant de l'individu IDuayant la clé publique pkudéterminée.
L'étape 840 est suivie de l'étape 850 d'envoi de l'identifiant de l'individu IDudéterminé.
Il est illustre à la un deuxième exemple de système dans lequel un serveur de contrôle détermine l'identité de l'individu ayant demandé une vérification d'une autorisation d'accès.
On ne décrira en détail ci-après que les étapes qui diffèrent de celles du premier exemple de système décrit à la . Pour le reste, il est renvoyé au premier exemple décrit au support de la .
Selon ce mode de réalisation, le serveur de contrôle CONTROL comprend une clé de divulgation secrète skoet une clé de divulgation publique pko.En outre, le serveur d'autorisation d'accès est tel que décrit à la et à la et comprend une donnée cryptographique publique Gpk. La donnée cryptographique publique Gpk est spécifique pour un groupe d'individus ayant au moins un attribut conforme à au moins une règle donnée. Ladite donnée cryptographique publique est associée à une donnée cryptographique secrète skm. La donnée cryptographique publique Gpk comprend une clé maitre publique pkmet une clé de divulgation publique pko, la clé de divulgation publique étant la clé publique du serveur de contrôle CONTROL.
La base de données d'individus BD-INDIV mémorise l'identifiant IDudes individus ayant demandé une donnée d'autorisation d'accès auprès du serveur d'autorisation d'accès selon le mode de réalisation décrit au support de la . A chaque identifiant IDud'individu est associée la clé publique pkude ce dernier.
En outre, la base de données de preuves BD-PREUVES comprend les différentes informations de preuves d'autorisation d'accès σ soumises par les individus au fournisseur de services pour montrer qu'ils sont légitimes à accéder au fournisseur de services tel que décrit au support de la . Dans la base de données de preuves BD-PREUVES, pour chaque information de preuve mémorisée σ, sont associées l'identifiant de demande de vérification SessionID et la donnée de vérification c. La date et l'heure de la réception de l'information de preuve d'autorisation d'accès par le serveur d'autorisation d'accès peuvent également être mémorisées pour chaque information de preuve mémorisée.
Le procédé de détermination de l'identifiant d'un individu mis en œuvre dans le serveur de contrôle CONTROL a pour objectif de lever l'anonymat de l'individu ayant demandé une vérification d'une autorisation d'accès.
Le procédé de détermination de l'identifiant d'un individu débute par les étapes 810 et 820 précédemment décrites au support de la . En outre, le procédé se poursuit à l'étape 925 par l'obtention par le serveur de contrôle de la donnée cryptographique publique Gpk, provenant du serveur d'autorisation d'accès SERV-AUTO. Le procédé se poursuit à l'étape 830 précédemment décrite au support de la .
Selon ce mode de réalisation, à l'issue des étapes 820, 925 et 830, le serveur de contrôle CONTROL a obtenu la donnée cryptographique publique Gpk, la donnée de vérification c, et l'information de preuve d'autorisation d'accès σ. A partir de la clé de divulgation secrète skoet des données et informations obtenues, le serveur de contrôle CONTROL détermine la clé publique de l'individu pkuqui a généré l'information de preuve d'autorisation d'accès σ.
Le procédé se poursuit alors à l'étape 840 précédemment décrite au support de la au cours de laquelle, à partir de la clé publique déterminée pku, le serveur de contrôle CONTROL va rechercher dans la base de données d'individus BD-INDIV l'identifiant de l'individu IDuayant la clé publique pkudéterminée.
L'étape 840 est suivie de l'étape 850 d'envoi de l'identifiant de l'individu IDudéterminé.

Claims (14)

  1. Procédé de délivrance d'une donnée d'autorisation d'accès pour un individu ayant une clé publique (pku) et au moins un attribut donné (ATT),
    le procédé étant mis en œuvre dans un serveur d'autorisation d'accès (SERV-AUTO) apte à communiquer avec un serveur d'identification (IDP) et un dispositif client (DEV),
    le serveur d'autorisation d'accès (SERV-AUTO) ayant au moins une règle donnée et une donnée cryptographique secrète, la donnée cryptographique secrète étant spécifique pour un groupe d'individus ayant au moins un attribut conforme à ladite au moins une règle donnée,
    le procédé comprenant les étapes suivantes :
    • obtention de la clé publique de l'individu (pku) (étape 220) ;
    • obtention dudit au moins un attribut (ATT) de l'individu provenant du serveur d'identification (IDP) (étape 240) ;
    • détermination d'une conformité dudit au moins un attribut (ATT) de l'individu obtenu à ladite au moins une règle donnée (étape 250) ;
    • si ledit au moins un attribut (ATT) de l'individu est conforme à ladite au moins une règle donnée, génération d'une donnée d'autorisation d'accès pour l'individu à partir de la donnée cryptographique secrète et de la clé publique de l'individu (pku) obtenue (étapes 260, 280) ;
    • délivrance de la donnée d'autorisation d'accès générée au dispositif client (DEV) (étape 290).
  2. Procédé selon la revendication précédente, caractérisé en ce que le serveur d'autorisation d'accès comprend en outre une donnée cryptographique publique associée à ladite donnée cryptographique secrète,
    et en ce que le procédé comprend en outre une étape de transmission de la donnée cryptographique publique au dispositif client (DEV).
  3. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que le procédé comprend en outre une étape de vérification de la possession d'une clé privée de l'individu (sku) par le dispositif client associée à la clé publique de l'individu (pku) obtenue, préalablement à la délivrance de la donnée d'autorisation d'accès.
  4. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que le procédé comprend en outre une étape d'obtention d'un identifiant de demande d'une donnée d'autorisation d'accès (étape 210) et une étape de transmission de l'identifiant de demande d'une donnée d'autorisation d'accès au serveur d'identification (IDP) (étape 230).
  5. Procédé selon la revendication précédente, caractérisé en ce que l'identifiant de demande d'une donnée d'autorisation d'accès comprend un identifiant de l'individu (IDu).
  6. Procédé selon l'une quelconque des revendications 1 à 4, caractérisé en ce que le procédé comprend en outre, une étape d'obtention d'un identifiant de l'individu (IDu) provenant du serveur d'identification (IDP) ou du dispositif client (DEV).
  7. Procédé de vérification d'une autorisation d'accès d'un individu ayant une donnée d'autorisation d'accès,
    la donnée d'autorisation d'accès ayant été délivrée conformément au procédé selon l'une quelconque des revendications 1 à 6,
    le procédé étant mis en œuvre dans un serveur d'autorisation d'accès (SERV-AUTO) apte à communiquer avec un fournisseur de services (FRS-SERV), le fournisseur de services mettant en œuvre un contrôle d'accès en fonction d'au moins un attribut de l'individu,
    le serveur d'autorisation d'accès (SERV-AUTO) ayant une donnée cryptographique publique, la donnée cryptographique publique étant spécifique pour un groupe d'individus ayant au moins un attribut conforme à au moins une règle donnée,
    ladite donnée cryptographique publique étant associée à une donnée cryptographique secrète,
    ladite donnée cryptographique secrète ayant été utilisée pour générer la donnée d'autorisation d'accès,
    le procédé comprenant les étapes suivantes :
    • réception d'une information de preuve d'autorisation d'accès, l'information de preuve d'autorisation d'accès ayant été générée au moyen de la donnée d'autorisation d'accès de l'individu (étape 510) ;
    • vérification de l'information de preuve d'autorisation d'accès reçue en utilisant la donnée cryptographique publique (étape 520) ;
    • si l'information de preuve d'autorisation d'accès est vérifiée, envoi au fournisseur de services (FRS-SERV) d'une information de validation de l'information de preuve d'autorisation d'accès, sans vérification de la conformité d'au moins un attribut de l'individu à ladite au moins une règle donnée lors de la vérification de l'autorisation d'accès (étapes 530, 550).
  8. Procédé selon la revendication précédente, caractérisé en ce que la donnée cryptographique publique est reçue du fournisseur de services (FRS-SERV) ou d'un dispositif client (DEV).
  9. Procédé selon la revendication 7 ou 8, caractérisé en ce que l'information de preuve d'autorisation d'accès est reçue du fournisseur de services (FRS-SERV) ou d'un dispositif client (DEV).
  10. Procédé selon la revendication 7 ou 8, caractérisé en ce que le serveur d'autorisation d'accès est en outre apte à communiquer avec un dispositif client (DEV), et en ce que le procédé comprend en outre, les étapes suivantes :
    • réception d'un identifiant de demande de vérification (SessionID) provenant du fournisseur de services (FRS-SERV) ;
    • génération d'une information de connexion à partir de l'identifiant de demande de vérification reçu ;
    • transmission au fournisseur de services (FRS-SERV) de l'information de connexion générée ;
    • création d'un canal de communication entre le serveur d'autorisation d'accès (SERV-AUTO) et le dispositif client (DEV) au moyen de l'information de connexion ;
    • réception de l'information de preuve d'autorisation d'accès du dispositif client (DEV) via le canal de communication créé.
  11. Procédé selon l'une quelconque des revendications 7 à 10, caractérisé en ce que le serveur d'autorisation d'accès est en outre apte à communiquer avec un dispositif client (DEV), et en ce que le procédé comprend en outre les étapes suivantes :
    • génération d'une donnée de vérification (c) ;
    • transmission de la donnée de vérification générée au dispositif client (DEV) ;
    • l'information de preuve d'autorisation d'accès reçue étant en outre générée à partir de la donnée de vérification.
  12. Procédé selon l'une quelconque des revendications 7 à 11, caractérisé en ce que le serveur d'autorisation d'accès (SERV-AUTO) est apte à communiquer avec une base de données de preuves (BD-PREUVES), et en ce que le procédé comprend en outre, une étape de transmission à ladite base de données de preuves (BD-PREUVES) de l'information de preuve d'autorisation d'accès reçue.
  13. Procédé selon l'une quelconque des revendications 7 à 12, caractérisé en ce que le serveur d'autorisation d'accès comprend en outre une donnée identifiant le groupe d'individus ayant au moins un attribut conforme à ladite au moins une règle donnée (IdToken), et en ce que l'étape d'envoi au fournisseur de services (FRS-SERV) d'une information de validation de l'information de preuve d'autorisation d'accès comprend en outre l'envoi de la donnée identifiant le groupe d'individus (IdToken).
  14. Dispositif configuré pour mettre en œuvre le procédé selon l'une quelconque des revendications 1 à 6 ou le procédé selon l'une quelconque des revendications 7 à 13.
FR2301862A 2023-02-28 2023-02-28 Procédé de délivrance d'une autorisation d'accès pour un individu et procédé de vérification Pending FR3146219A1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
FR2301862A FR3146219A1 (fr) 2023-02-28 2023-02-28 Procédé de délivrance d'une autorisation d'accès pour un individu et procédé de vérification
EP24707069.1A EP4674088A1 (fr) 2023-02-28 2024-02-27 Procédé de delivrance d'une autorisation d'accès pour un individu et procédé de vérification
PCT/EP2024/054930 WO2024180049A1 (fr) 2023-02-28 2024-02-27 Procede de delivrance d'une autorisation d'acces pour un individu et procede de verification

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2301862A FR3146219A1 (fr) 2023-02-28 2023-02-28 Procédé de délivrance d'une autorisation d'accès pour un individu et procédé de vérification
FR2301862 2023-02-28

Publications (1)

Publication Number Publication Date
FR3146219A1 true FR3146219A1 (fr) 2024-08-30

Family

ID=86764643

Family Applications (1)

Application Number Title Priority Date Filing Date
FR2301862A Pending FR3146219A1 (fr) 2023-02-28 2023-02-28 Procédé de délivrance d'une autorisation d'accès pour un individu et procédé de vérification

Country Status (3)

Country Link
EP (1) EP4674088A1 (fr)
FR (1) FR3146219A1 (fr)
WO (1) WO2024180049A1 (fr)

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
ASGHAR MUHAMMAD RIZWAN ET AL: "PRIMA: Privacy-Preserving Identity and Access Management at Internet-Scale", 2018 IEEE INTERNATIONAL CONFERENCE ON COMMUNICATIONS (ICC), IEEE, 20 May 2018 (2018-05-20), pages 1 - 6, XP033378717, DOI: 10.1109/ICC.2018.8422732 *
NABEEL MOHAMED ET AL: "Privacy Preserving Policy-Based Content Sharing in Public Clouds", IEEE TRANSACTIONS ON KNOWLEDGE AND DATA ENGINEERING, IEEE SERVICE CENTRE , LOS ALAMITOS , CA, US, vol. 25, no. 11, 1 November 2013 (2013-11-01), pages 2602 - 2614, XP011527657, ISSN: 1041-4347, [retrieved on 20130919], DOI: 10.1109/TKDE.2012.180 *
ZÚQUETE ANDRÉ ET AL: "Personal Identification in the Web Using Electronic Identity Cards and a Personal Identity Provider", 2 July 2014, SAT 2015 18TH INTERNATIONAL CONFERENCE, AUSTIN, TX, USA, SEPTEMBER 24-27, 2015; [LECTURE NOTES IN COMPUTER SCIENCE; LECT.NOTES COMPUTER], SPRINGER, BERLIN, HEIDELBERG, PAGE(S) 160 - 169, ISBN: 978-3-540-74549-5, XP047476688 *

Also Published As

Publication number Publication date
EP4674088A1 (fr) 2026-01-07
WO2024180049A1 (fr) 2024-09-06

Similar Documents

Publication Publication Date Title
CA2875563C (fr) Securite d'authentification 2chk amelioree comportant des transactions d'interrogation
CA2875503C (fr) Association 2chk declenchee par entreprise
US8627424B1 (en) Device bound OTP generation
US9165149B2 (en) Use of a mobile telecommunication device as an electronic health insurance card
EP1549011A1 (fr) Procédé et système de communication entre un terminal et au moins un équipment communicant
WO2013079848A1 (fr) Protocole d'authentification mutuelle d' entitees ayant prealablement initie une transaction en ligne
EP2220812A2 (fr) Procedé d'authentification d'un utilisateur
FR2973909A1 (fr) Procede d'acces a une ressource protegee d'un dispositif personnel securise
CN114462013A (zh) 基于jsbridge的应用接入方法及系统
JP2001216270A (ja) 認証局、認証システム及び認証方法
KR20180037168A (ko) Otp를 이용한 상호 인증 방법 및 시스템
WO2009056374A1 (fr) Procede d'authentification d'un utilisateur accedant a un serveur distant a partir d'un ordinateur
FR3146219A1 (fr) Procédé de délivrance d'une autorisation d'accès pour un individu et procédé de vérification
US12446630B1 (en) Systems and methods for discovering and controlling electronic devices
US20100325433A1 (en) Login system
FR3118225A1 (fr) Procédé et dispositif de génération d'informations d'authentification pour une entité sécurisée et procédé et dispositif de contrôle d'identité associés
WO2012022856A1 (fr) Procédé d'authentification d' un utilisateur du réseau internet
FR3007929A1 (fr) Procede d'authentification d'un utilisateur d'un terminal mobile
EP2630746A1 (fr) Procede et systeme d'authentification
HK1207714B (en) Enhanced 2chk authentication security with query transactions
HK1207713B (en) Enterprise triggered 2chk association

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20240830

PLFP Fee payment

Year of fee payment: 3

PLFP Fee payment

Year of fee payment: 4

CA Change of address

Effective date: 20260126