Titre : Procédé et dispositif d’authentification d’un utilisateur auprès d’une application.

1. Domaine de l'invention

L’invention se rapporte au domaine général des réseaux de télécommunications, et plus précisément à la technologie des chaînes de blocs (en anglais « blockchain »).

2. Art Antérieur

Nous vivons dans un monde toujours plus connecté, conséquence d’une digitalisation de plus en plus poussée de nos processus traditionnels tels que les courriers, les démarches administratives, les services bancaires, le paiement, etc. Pour accéder aux services digitalisés et à leurs contenus/fonctionnalités, il est souvent demandé à un utilisateur de s’identifier grâce à une identité numérique. Cette identité numérique est le plus souvent différente d’un service à un autre ce qui implique une multitude d’ identifiants à mémoriser pour Tutilisateur.

Il existe aujourd’hui des solutions pour résoudre ce problème comme par exemple les solutions de type SSO (Single Sign-On) qui propose à Tutilisateur de se connecter à de multiples applications via un seul identifiant. Concrètement, ces solutions reposent sur la délégation de l’authentification à des fournisseurs d’identités ou IdP pour « Identity Providers » qui créent, gèrent et maintiennent l’identité d’un utilisateur pour le compte de fournisseurs de services. Les fournisseurs d’identités sont par exemple de type SAML (Security Assertion Markup Language) ou OIDC (OpenID Connect).

La délégation de l’authentification à des fournisseurs d’identités peut poser un problème concernant la protection des données à caractère personnel. En effet, ces solutions imposent à Tutilisateur de partager au préalable avec le ou les fournisseurs d’identités de nombreuses données personnelles. Un acteur malveillant qui proposerait un tel service pourrait récupérer des données sensibles des utilisateurs et les revendre sans que les utilisateurs en aient conscience. De plus, Tutilisateur n’a pas le contrôle sur le nombre et la nature des informations communiquées aux services digitaux par le fournisseur d’identités lors des demandes d’authentification. 3. Exposé de l'invention

L’invention vient améliorer l’état de la technique et propose un procédé d’authentification d’un utilisateur auprès d’au moins une application, dite application de services, ledit utilisateur étant équipé d’un dispositif utilisateur possédant au moins une adresse et étant apte à obtenir au moins une donnée d’authentification dudit utilisateur, le procédé étant mis en œuvre par un dispositif d’authentification d’un utilisateur et caractérisé en ce qu’il comprend :

- une étape de réception, en provenance de ladite au moins une application de services, d’une requête comprenant au moins un identifiant dudit utilisateur ; une première étape d’émission, à destination d’une application inscrite à une chaîne de blocs, d’une requête comprenant ledit au moins un identifiant dudit utilisateur ;

- une deuxième étape de réception, en réponse à l’étape d’émission, d’un message comprenant au moins une première donnée correspondant à une première adresse dudit dispositif utilisateur, ladite au moins une première donnée ayant été obtenue en fonction dudit au moins un identifiant dudit utilisateur ;

- une deuxième étape d’émission, à destination de ladite première adresse, d’une requête pour émettre un message comprenant ladite au moins une donnée d’authentification dudit utilisateur vers une adresse de ladite application de services.

Ainsi, le fournisseur de services qui souhaite authentifier un utilisateur va solliciter le dispositif d’authentification en lui partageant un identifiant renseigné par exemple par l’utilisateur au niveau de l’interface homme-machine du service. Le dispositif d’authentification va alors récupérer, depuis une application inscrite à une chaîne de blocs, une adresse d’un dispositif appartenant à l’utilisateur. Ce dispositif utilisateur est par exemple une clef de sécurité USB, un mobile, un PC, une machine virtuelle située dans le réseau, ou tout autre terminal apte à obtenir et fournir des données par exemple chiffrées d’un utilisateur permettant son authentification comme par exemple des jetons d’authentification. Une fois l’adresse du dispositif utilisateur récupérée, le procédé va contacter le dispositif utilisateur via une requête de redirection redirigeant vers l’adresse du service qui souhaite procéder à l’authentification de l’utilisateur. Lors de la redirection, le dispositif de l’utilisateur complète la requête avec une donnée d’authentification telle qu’un jeton d’authentification. Le jeton peut par exemple être généré par le dispositif utilisateur en fonction de données renseignées par l’utilisateur telles que des données biométriques. On entend par application de services, toute application apte à rendre au moins un service pour les besoins d’un utilisateur et exécutée par exemple sur un serveur situé dans un réseau tel que le réseau Internet. L’application peut également être exécutée au niveau d’un terminal comme par exemple un objet connecté, un smartphone (téléphone intelligent en anglais), un ordinateur personnel, ou tout autre terminal apte à exécuter une application informatique.

Avantageusement, ce procédé permet de garantir l’identité de l’utilisateur grâce à l’utilisation de la chaîne de blocs. Comme indiqué dans le document (https://ff.wikipedia.org/wiki/Blockchain), on rappelle que « la technologie des chaînes de blocs est une technologie de stockage et de transmission d'informations sans organe de contrôle. Techniquement, il s'agit d'une base de données distribuée dont les informations envoyées par les utilisateurs et les liens internes à la base sont vérifiés et groupés à intervalles de temps réguliers en blocs, l'ensemble étant sécurisé par cryptographie, et formant ainsi une chaîne. Par extension, une chaîne de blocs est une base de données distribuée qui gère une liste d'enregistrements protégés contre la falsification ou la modification par les nœuds de stockage ; c'est donc un registre distribué et sécurisé de toutes les transactions effectuées depuis le démarrage du système réparti». Les chaînes de blocs sont caractérisées en outre en ce que leurs contenus ne peuvent pas être modifiés ou supprimés : une information publiée dans une chaîne de blocs le reste pour toujours. Nous désignons par information « publiée » dans une chaîne de blocs, une information enregistrée ou sauvegardée dans celle-ci.

Selon un mode de mise en œuvre particulier de l'invention, un procédé tel que décrit ci- dessus est caractérisé en ce que la première étape d’émission est suivie :

- d’une troisième étape de réception, en provenance de ladite application de services, d’une requête d’attributs dudit utilisateur, ladite requête comprenant ladite au moins une donnée d’authentification et ledit au moins un identifiant dudit utilisateur ;

- d’une troisième étape d’émission, à destination d’une deuxième adresse d’un dispositif dudit utilisateur obtenue en fonction dudit au moins un identifiant dudit utilisateur, d’une requête d’attributs dudit utilisateur ;

- d’une quatrième étape de réception d’une réponse à la requête d’attributs, la réponse comportant au moins un attribut dudit utilisateur ; - d’une quatrième étape d’émission, à destination de ladite application de services, d’une réponse à la requête d’attributs, la réponse comportant au moins une deuxième donnée.

Ce mode de mise en œuvre de l'invention permet de fournir, à l’issue de G authentification, au moins une donnée au fournisseur du service comme par exemple un ou des attributs de l’utilisateur, un code d’erreur, etc. nécessaires au bon fonctionnement du service. Avantageusement, le mode de réalisation permet à l’utilisateur de rester maître des attributs qu’il partage avec les fournisseurs de services. Il peut connaître les données demandées par le fournisseur de service et accepter en connaissance de cause de les partager ou non.

On entend par attribut une donnée personnelle de l’utilisateur telle qu’un nom, prénom, numéro de téléphone, empreinte biométrique, adresse postale, adresse e-mail, âge, profession, etc. l’attribut peut être également un objet multimédia tel qu’une photo, une vidéo, un document de texte, etc.

Selon un mode de mise en œuvre particulier de l'invention, un procédé tel que décrit ci- dessus est caractérisé en ce que la quatrième étape d’émission est précédée :

- d’une étape d’obtention, depuis une entité de confiance, d’au moins une troisième donnée obtenue par application d’une fonction audit au moins un attribut dudit utilisateur;

- d’une étape de génération d’au moins une quatrième donnée obtenue par application de ladite fonction audit au moins un attribut dudit utilisateur reçu lors de la quatrième étape de réception ;

- d’une étape d’ajout dudit au moins un attribut dudit utilisateur au contenu de ladite au moins une deuxième donnée en fonction du résultat de la comparaison de ladite au moins une troisième donnée avec ladite au moins une quatrième donnée.

Ce mode de réalisation permet d’assurer que les attributs de l’utilisateur sont valides. Le dispositif va par exemple obtenir, depuis une entité de confiance, un hash (empreinte numérique servant à identifier rapidement une donnée initiale réalisée via une fonction qui prend en entrée la donnée) de l’attribut de l’utilisateur et le comparer avec le hash de l’attribut de l’utilisateur généré par le dispositif d’authentification lui-même. Si les deux hash correspondent, alors les attributs reçus sont considérés comme valides. Ils sont alors insérés dans les données envoyées par le procédé d’authentification à l’application de services. On appelle entité de confiance un dispositif tel qu’un serveur, un ordinateur personnel, un terminal mobile, un objet connecté apte à obtenir par exemple d’un utilisateur et à fournir des données certifiées telles que des attributs d’un utilisateur.

Selon un mode de mise en œuvre particulier de l'invention, un procédé tel que décrit ci- dessus est caractérisé en ce que l’entité de confiance est une application inscrite à une chaîne de blocs.

Ce mode de réalisation permet de s’assurer que les preuves n’ont pas été corrompues, les données inscrites dans une chaîne de blocs ne pouvant être modifiées ou supprimées.

Selon un mode de mise en œuvre particulier de l'invention, un procédé tel que décrit ci- dessus est caractérisé en ce que ladite première adresse correspond à ladite deuxième adresse dudit dispositif utilisateur.

Ce mode de réalisation permet d’utiliser le même terminal utilisateur pour récupérer la ou les données d’authentification et le ou les attributs.

Selon un mode de mise en œuvre particulier de l'invention, un procédé tel que décrit ci- dessus est caractérisé en ce que ledit au moins un attribut est une donnée chiffrée et en ce que l’étape de génération est précédée d’une étape de déchiffrement dudit au moins un attribut.

Ce mode de réalisation permet à l’utilisateur de ne pas transmettre en clair ses attributs ou données personnelles.

L’invention concerne également un dispositif d’authentification d’un utilisateur auprès d’au moins une application, dite application de services, ledit utilisateur étant équipé d’un dispositif utilisateur apte à obtenir au moins une donnée d’authentification dudit utilisateur, et caractérisé en ce qu’il comprend :

- un module de réception d’une requête en provenance de ladite au moins une application de services comprenant au moins un identifiant dudit utilisateur ; un module d’émission à destination d’une application inscrite à une chaîne de blocs d’une requête comprenant ledit au moins un identifiant dudit utilisateur ;

- un deuxième module de réception d’un message de réponse, en provenance de ladite application inscrite à une chaîne de blocs, comprenant au moins une première donnée correspondant à une première adresse dudit dispositif utilisateur, ladite au moins une première donnée ayant été obtenue en fonction dudit au moins un identifiant dudit utilisateur ;

- un deuxième module d’émission, à destination de ladite première adresse, d’une requête pour émettre un message, vers une adresse de ladite application de services, comprenant ladite au moins une donnée d’authentification dudit utilisateur.

Le terme module peut correspondre aussi bien à un composant logiciel qu’à un composant matériel ou un ensemble de composants matériels et logiciels, un composant logiciel correspondant lui-même à un ou plusieurs programmes ou sous-programmes d’ordinateur ou de manière plus générale à tout élément d’un programme apte à mettre en œuvre une fonction ou un ensemble de fonctions telles que décrites pour les modules concernés. De la même manière, un composant matériel correspond à tout élément d’un ensemble matériel (ou hardware) apte à mettre en œuvre une fonction ou un ensemble de fonctions pour le module concerné (circuit intégré, carte à puce, carte à mémoire, etc.).

L'invention concerne également un serveur caractérisé en ce qu’il comporte un dispositif d’authentification d’un utilisateur tel que décrit précédemment.

L'invention concerne également un programme d'ordinateur comportant des instructions pour la mise en œuvre du procédé ci-dessus selon l’un quelconque des modes particuliers de réalisation décrits précédemment, lorsque ledit programme est exécuté par un processeur. Le procédé peut être mis en œuvre de diverses manières, notamment sous forme câblée ou sous forme logicielle. Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n’importe quelle autre forme souhaitable.

L’invention vise aussi un support d’enregistrement ou support d’informations lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci- dessus. Les supports d’enregistrement mentionnés ci-avant peuvent être n’importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu’une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple un disque dur. D'autre part, les supports d'enregistrement peuvent correspondre à un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Les programmes selon l'invention peuvent être en particulier téléchargés sur un réseau de type Internet.

Alternativement, les supports d'enregistrement peuvent correspondre à un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question.

Ce dispositif d’authentification d’un utilisateur et ce programme d'ordinateur présentent des caractéristiques et avantages analogues à ceux décrits précédemment en relation avec le procédé d’authentification d’un utilisateur.

4. Liste des figures

D’autres caractéristiques et avantages de l’invention apparaîtront plus clairement à la lecture de la description suivante de modes de réalisation particuliers, donnés à titre de simples exemples illustratifs et non limitatifs, et des dessins annexés, parmi lesquels :

[Fig 1] La figure 1 représente l’architecture matérielle d’un dispositif d’authentification selon un mode particulier de réalisation de l’invention ;

[Fig 2] La figure 2 représente sous forme d’organigramme les principales étapes d’un procédé d’authentification selon un mode particulier de réalisation de l’invention.

5. Description d’un mode de réalisation de l’invention

La figure 1 représente l’architecture matérielle d’un dispositif d’authentification DA conforme à l’invention. Dans le mode de réalisation décrit ici, ce dispositif a l’architecture matérielle d’un ordinateur. Il comprend notamment un processeur PROC1, une mémoire vive MV1, une mémoire morte MEM1 et une mémoire flash non volatile MF1. De tels moyens sont connus en soi et ne sont pas décrits plus en détail ici. La mémoire morte constitue un support d’enregistrement conforme à l’invention, lisible par le processeur PROC1 et sur lequel est enregistré ici un programme d’ordinateur PG1 conforme à l’invention, ce programme comportant des instructions pour mettre en œuvre les étapes du procédé de contrôle d’accès à une fonction tel que décrit précédemment, lorsque le programme est exécuté par le processeur PROC1. A l'initialisation, les instructions de code du programme d’ordinateur PG1 sont par exemple chargées dans une mémoire avant d’être exécutées par le processeur PROC1. Le processeur PROC1 de l'unité de traitement UT1 met notamment en œuvre les étapes du procédé de contrôle d’accès à une fonction selon l'un quelconque des modes particuliers de réalisation décrits en relation avec la figure 2, selon les instructions du programme d'ordinateur PG1.

Le dispositif DA comprend également des modules de réception RECV1 et RECV2 aptes recevoir des communications via par exemple un réseau IP et/ou circuit. Le module de réception RECV 1 est par exemple utilisé pour recevoir des requêtes en provenance d’une application de services comprenant au moins un identifiant d’un utilisateur. Le module de réception RECV2 est par exemple utilisé pour recevoir un message comprenant au moins une donnée correspondant à une adresse d’un dispositif d’un utilisateur.

Selon un mode particulier de réalisation de l’invention, les modules RECV1 et RECV2 peuvent être un seul et même module de réception.

Le dispositif DA comprend en outre des modules d’émission SND1 et SND2 aptes à émettre des communications via par exemple un réseau IP et/ou circuit. Le module d’émission SND1 est par exemple utilisé pour émettre, à destination d’une application inscrite à une chaîne de blocs, une requête comprenant au moins un identifiant d’un utilisateur. Le module SND2 est par exemple utilisé pour émettre, à destination d’une adresse d’un dispositif utilisateur, une requête permettant l'émission d’un message, vers une adresse d’une application de services comprenant au moins une donnée d’authentification d’un utilisateur. Selon un mode particulier de réalisation de l’invention, les modules SND1 et SND2 peuvent être un seul et même module de réception.

Selon un mode particulier de réalisation de l’invention, les modules RECV1, RECV2, SND1 et SND2 peuvent être un seul et même module de communication COM1 (non représenté).

Selon un mode particulier de réalisation de l’invention, le module de communication COM1 peut aussi être utilisé pour recevoir, en provenance d’une application de services, une requête d’attributs d’un utilisateur et comprenant au moins une donnée d’authentification et un identifiant de l’utilisateur.

Selon un mode particulier de réalisation de l’invention, le module de communication COM1 peut aussi être utilisé pour émettre à destination d’une adresse d’un dispositif de l’utilisateur une requête d’attributs de l’utilisateur, l’adresse du dispositif ayant été obtenue en fonction d’un identifiant de utilisateur par exemple via une application inscrite à une chaîne de blocs ou depuis un espace de stockage numérique tel qu’une base de données, un fichier ou une mémoire. Le module de communication COM1 peut également être utilisé pour recevoir une réponse à la requête d’attributs, la réponse comportant au moins un attribut de Putilisatcur ou un message de statut tel qu’un code d’erreur.

Selon un mode particulier de réalisation de l’invention, le module de communication COM1 peut aussi être utilisé pour émettre à destination d’une application de services, une réponse à la requête d’attributs provenant de l’application de services, comportant au moins une donnée telle qu’un code d’erreur, un statut, un identifiant de transaction, un attribut, etc.

Selon un mode particulier de réalisation de l’invention, le dispositif DA comprend un module d’obtention (OBT) apte à obtenir depuis une entité de confiance au moins une donnée, dite preuve, obtenue par application d’une fonction Fl à un ou plusieurs attributs de l’utilisateur. La fonction Fl est par exemple une fonction permettant de créer un hash et/ou une fonction permettant le chiffrement et/ou une fonction permettant de signer le ou les attributs de l’utilisateur. Elle peut être exécutée par exemple par l’entité de confiance ou bien par un dispositif utilisateur ou tout autre dispositif apte à fournir la ou les preuves à l’entité de confiance.

Selon un mode particulier de réalisation de l’invention, le dispositif DA comprend un module de génération (GEN) apte à générer la ou les preuves, par application de la fonction Fl à un ou plusieurs attributs de l’utilisateur reçus via le module COM1. La ou les preuves générées peuvent être ensuite comparées par le module de comparaison (COMP) aux preuves obtenues via le module d’obtention OBT. Si le résultat de la comparaison est positif alors les attributs sont considérés comme valides. Dans le cas contraire les attributs sont considérés comme non valides.

Selon un mode particulier de réalisation de l’invention, le dispositif DA comprend un module (non représenté) permettant le déchiffrement des preuves obtenues. Ce mode de réalisation permet par exemple de déchiffrer les preuves obtenues avant de pouvoir les comparer aux preuves générées par le dispositif DA.

Selon un mode particulier de réalisation de l’invention, les modules COM1 et OBT peuvent être un seul et même module de communication. En référence à la figure 2, nous allons maintenant décrire les principales étapes E20, E21, E22, E23, E25, E26, E27, E28 et E29 d’un procédé d’authentification selon des modes de réalisation de l’invention.

La figure 2 est constituée d’un terminal T comme par exemple un terminal mobile, une clef USB (Universal Serial Bus), un objet connecté ou un ordinateur apte à obtenir et fournir des données par exemple chiffrées d’un utilisateur permettant son authentification comme par exemple des jetons d’authentification ou des données personnelles. La figure 2 comprend également un dispositif BC inscrit à une chaîne de blocs par exemple apte à exécuter des fonctions décentralisées ou DApps au sens de la technologie des chaînes de blocs mais aussi un dispositif SA tel qu’un serveur, un ordinateur personnel, un objet connecté ou tout autre terminal apte à fournir un service à un utilisateur. Elle est en outre constituée d’un dispositif DA apte à exécuter le procédé d’authentification au sens de l’invention.

Au cours d’une première étape E10, le dispositif SA envoie une demande d’authentification au dispositif DA. Cette demande fait suite à une requête émise par un terminal d’un utilisateur pour accéder à un service fourni par le dispositif DA.

A l’étape E20 le dispositif d’authentification DA reçoit la demande d’authentification qui peut comprendre plusieurs paramètres tel qu’un identifiant de l’utilisateur souhaitant accéder au service fourni par le dispositif SA, un numéro de transaction, un identifiant de service, un identifiant du dispositif SA, une adresse du dispositif SA, une plage horaire, ou tout autre information liée au service ou à l’utilisateur.

A l’étape E21, le procédé d’authentification va émettre à destination du dispositif BC une requête comprenant au moins un identifiant de l’utilisateur récupéré lors de l’étape E20. La requête est ensuite reçue par le dispositif BC à l’étape E31.

A l’étape E32, le dispositif BC va renvoyer au dispositif DA une réponse contenant une adresse, comme par exemple une adresse MAC ou une adresse IP, d’un terminal T appartenant à l’utilisateur. L’adresse du terminal T correspond à une première donnée au sens de l’invention. Cette adresse est sélectionnée par le dispositif BC en fonction de l’identifiant de l’utilisateur reçu à l’étape E31.

Selon un mode particulier de réalisation de l’invention, le dispositif BC peut envoyer une réponse comprenant une liste d’adresses de dispositifs de l’utilisateur, cette liste pouvant par exemple être ordonnée, la première adresse étant par exemple celle à utiliser par défaut. Les adresses peuvent également être associées à une donnée indiquant la nature des données qu’il est possible d’obtenir via chaque dispositif utilisateur (donnée d’authentification, attributs utilisateurs, etc.).

La réponse du dispositif BC est ensuite reçue par le dispositif DA à l’étape E22. Une fois l’adresse du terminal T reçue par le dispositif DA, celui-ci va émettre (E23) à destination de l’adresse du terminal T une requête de redirection, c’est-à-dire une requête demandant au terminal T d’émettre à son tour un message, à destination du dispositif SA. La requête émise par le dispositif DA à l’étape E23 et reçue par le terminal T à l’étape E43, peut comprendre des paramètres tels que l’identifiant du service fourni par le dispositif SA et/ou l’adresse du dispositif SA et/ou toute autre information telle qu’un paramètre fourni par le dispositif SA et reçu par le dispositif DA lors de l’étape E20. Le message émise par le terminal T à l’étape E44 et reçue par le dispositif SA à l’étape E14 comprend au moins une donnée d’authentification de l’utilisateur comme par exemple une donnée personnelle ou un jeton d’ authentification.

A noter que les données d’authentification peuvent être générées au niveau du terminal T via par exemple des données collectées par un capteur biométrique utilisé pour obtenir une empreinte digitale, un iris, un visage, une voix, etc. de l’utilisateur.

Selon un mode particulier de réalisation de l’invention, la donnée d’authentification peut varier en fonction d’un ou de plusieurs paramètres par exemple reçus par le terminal T à l’étape E43 et/ou obtenus par le terminal T comme par exemple l’heure courante obtenue via une horloge interne au dispositif T. Dans le cas où l’un des paramètres est un paramètre de la requête reçue lors de l’étape E43, celui-ci peut être un paramètre reçu précédemment par le dispositif DA lors de l’étape E20 tel qu’une plage horaire, un identifiant du service ou du dispositif SA.

Selon un mode particulier de réalisation de l’invention, le dispositif SA émet lors de l’étape E15 une demande d’attributs de l’utilisateur à destination du dispositif DA. La requête comprend au moins une donnée d’authentification reçue par le dispositif SA lors de l’étape E14 et un identifiant de l’utilisateur qui est par exemple le même que celui transmis dans la requête émise par le dispositif SA lors de l’étape E10. Elle peut comprendre également d’autres paramètres comme un identifiant de service exécuté par le dispositif SA, un numéro de transaction, un identifiant du dispositif SA, ou tout autre information liée au service. Le dispositif DA reçoit la requête à l’étape E25 et va à l’étape E26 émettre une requête d’attributs à destination d’un dispositif de l’utilisateur. Cette requête d’attributs peut comprendre des paramètres reçus du dispositif SA lors de l’étape E25. La requête est reçue à l’étape E46 par le dispositif utilisateur qui est dans le cas décrit à l’appui de la figure 2 le terminal T.

Selon une variante de ce mode de mise en œuvre particulier, le dispositif utilisateur qui reçoit la requête d’attribut (E46) peut être différent du dispositif utilisateur qui reçoit la requête de redirection (E43).

A l’étape E47, le terminal T transmet au dispositif DA un ou des attributs de l’utilisateur.

Les attributs sont par exemple fonction d’un identifiant de service, d’un numéro de transaction, d’un identifiant du dispositif SA, ou tout autre information liée au service et reçue lors de l’étape E46. Le dispositif DA reçoit le ou les attributs de l’utilisateur à l’étape E27 puis va le ou les transmettre au dispositif SA lors de l’étape E29. Le ou les attributs sont ensuite reçus par le dispositif SA à l’étape El 9.

Selon un mode particulier de réalisation de l’invention, le dispositif DA peut, après avoir récupéré les attributs de l’utilisateur (E27), déchiffrer via par exemple une clef partagée avec le terminal T les attributs avant de les transmettre au dispositif SA (E29).

Selon un mode particulier de réalisation de l’invention, le dispositif DA peut, après avoir récupéré les attributs de l’utilisateur (E27), vérifier la signature des attributs via par exemple une clef partagée avec le terminal T avant de les transmettre au dispositif SA (E29).

Les processus de chiffrement et/ou de signature des attributs par des clefs partagées entre le terminal T et le dispositif DA sont des procédés connus de l’état de l’art et de ce fait ne sont pas décrits plus en détail ici.

Selon un mode particulier de réalisation de l’invention, le dispositif DA peut obtenir depuis une entité de confiance (non représentée) un ou plusieurs hash d’un attribut, de plusieurs attributs ou d’une concaténation d’attributs de l’utilisateur. Le dispositif DA va alors calculer le hash d’un attribut, de plusieurs attributs ou d’une concaténation d’attributs récupérés de l’utilisateur lors de l’étape E27 en appliquant la même fonction que celle qui a permis de générer le ou les hash obtenus depuis l’entité de confiance. Le dispositif va ensuite, lors de l’étape E28, comparer le ou les hash calculés avec ceux obtenus de l’entité de confiance. Si le résultat de la comparaison est positif alors les attributs sont considérés comme valides. Dans le cas contraire les attributs sont considérés comme non valides et un message d’erreur comme par exemple un code est renvoyé au dispositif SA lors de l’étape E29. Il va de soi que le mode de réalisation qui a été décrit ci-dessus a été donné à titre purement indicatif et nullement limitatif, et que de nombreuses modifications peuvent être facilement apportées par l’homme de l’art sans pour autant sortir du cadre de l’invention.