FR3167516A3 - Procédé et dispositif de fourniture d’un attribut d’une identité numérique certifiée d’un correspondant d’une communication électronique. - Google Patents

Abstract

L'invention concerne un procédé de fourniture d’au moins un attribut d’au moins une identité numérique certifiée d’un correspondant d’une communication électronique établie ou en cours d’établissement entre au moins un premier terminal d’un premier utilisateur et un second terminal d’un second utilisateur, ledit procédé étant mis en œuvre par un dispositif de fourniture et caractérisé en ce que le procédé comprend : une première étape d’obtention, d’une demande d’au moins un attribut d’au moins une identité numérique certifiée dudit premier utilisateur, ladite demande étant reçue en provenance d’un module de communication dudit second terminal ;une deuxième étape d’obtention, depuis un portefeuille d’identités numériques, dudit au moins un attribut ;une troisième étape d’émission, à destination dudit module de communication, dudit au moins un attribut. Figure pour l'abrégé : Figure 1

Description

Procédé et dispositif de fourniture d’un attribut d’une identité numérique certifiée d’un correspondant d’une communication électronique.

1. Domaine de l'invention

L'invention concerne le domaine des télécommunications et plus particulièrement un procédé qui permet, au cours d’une communication, de s’assurer de l’identité de son correspondant.

2. Art Antérieur

Les utilisateurs des services de télécommunications (téléphonie, visiophonie, SMS, RCS, messagerie Instantanée, mail, etc.) reçoivent de plus en plus de communications électroniques non sollicitées avec à la clef de nombreux désagréments. C’est par exemple le cas lorsque ceux-ci reçoivent des appels émis lors de campagnes d’hameçonnage (phishing en anglais).

On observe, ainsi, une augmentation des appels téléphoniques en provenance de fraudeurs incitant leurs interlocuteurs à valider, à leur détriment (par exemple sur leur terminal mobile), des opérations bancaires et/ ou des autorisations d’accès à leur compte (contexte de la Directive des Services de Paiement n°2). Au cours de ces appels malveillants, le fraudeur usurpe le numéro d’appelant de la banque de l’appelé afin de se forger une image de conseiller bancaire. Pour ce faire, les fraudeurs peuvent, par exemple, déclarer le numéro de téléphone de la banque dans l’entête SIP FROM du protocole SIP (Session Initiation Protocol) permettant l’établissement de la communication téléphonique.

Une fois la communication établie, les fraudeurs utilisent des stratégies d’ingénierie sociale (exploitation de données personnelles, mise en confiance, situation d’urgence, horaires décalés ou/et inhabituels…) afin, par exemple, de convaincre l’appelant de valider des opérations bancaires par authentification forte.

Des solutions pour lutter contre de tels agissements existent. Elles sont principalement basées sur des mécanismes de listes dites DNO (en anglais Do Not Originate) qui dénombrent les numéros d’un organisme / d’une société qui ne sont jamais utilisés en appel sortant, ce qui permet à l’opérateur de l’appelant ou de l’appelé de « casser » un appel qui soi-disant émanerait d’un tel numéro. C’est une réponse très partielle, qui se borne à fiabiliser quelques numéros détenus par l’organisme usurpé.

Une autre solution consiste à utiliser les mécanismes STIR/SHAKEN associés au protocole SIP qui ont pour but de certifier l’identité d’appelant (Caller ID) au moyen d’un certificat (signé par un mécanisme de clé cryptographique) délivré par une autorité de confiance. Cependant, ce procédé ne résiste pas à certaines interconnexions internationales ou aux changements de protocoles de signalisation le long du chemin d’appel (exemple SS7 / SIP). Ainsi, leur mise en œuvre effective pour tous les appels reste à l’heure actuelle un problème.

Il existe donc un besoin pour une solution plus fiable qui permette de connaitre de façon certaine l’identité de son correspondant.

3. Exposé de l'invention

L'invention vient améliorer l'état de la technique et propose un procédé de fourniture d’au moins un attribut d’au moins une identité numérique certifiée d’un correspondant d’une communication électronique établie ou en cours d’établissement entre au moins un premier terminal d’un premier utilisateur et un second terminal d’un second utilisateur, ledit procédé étant mis en œuvre par un dispositif de fourniture et caractérisé en ce que le procédé comprend :

• une première étape d’obtention, d’une demande d’au moins un attribut d’au moins une identité numérique certifiée dudit premier utilisateur, ladite demande étant reçue en provenance d’un module de communication dudit second terminal ;
• une deuxième étape d’obtention, depuis un portefeuille d’identités numériques, dudit au moins un attribut ;
• une troisième étape d’émission, à destination dudit module de communication, dudit au moins un attribut.

Avantageusement, selon l'invention, une communication établie entre un terminal émetteur et un terminal récepteur peut être déterminée comme frauduleuse par l’appelé, c’est-à-dire émise par un appelant malveillant, lorsque, par exemple, tout ou partie d’une identité certifiée de l’appelant reçue par l’appelé (le ou les attributs au sens de l’invention) n’est pas en adéquation avec une identité non certifiée de l’appelant présentée à l’appelé lors de l’établissement de la communication (par exemple via un service permettant la présentation de numéro de l’appelant à l’appelé) ou lorsque tout ou partie d’une identité certifiée de l’appelant reçue n’est pas connue de l’appelé.

L'invention permet également à un appelant de s’assurer de l’identité de l’appelé lorsque, par exemple, tout ou partie d’une identité certifiée de l’appelé reçue par l’appelant (le ou les attributs au sens de l’invention) n’est pas en adéquation avec une identité non certifiée de l’appelé, par exemple le numéro de téléphone de l’appelé, utilisé lors de l’établissement de la communication (cas d’un changement de numéro de téléphone).

Ainsi, le procédé peut avantageusement être exécuté en lien avec le terminal de l’appelé ou avec le terminal de l’appelant.

Concrètement, le procédé obtient une demande d’un ou de plusieurs attributs d’une identité numérique certifiée d’un premier correspondant/utilisateur, la demande étant émise par un second correspondant/utilisateur et plus particulièrement par un module de communication de son terminal (second terminal au sens de l’invention) et les premier et second correspondants étant impliqués dans la même communication électronique. Le procédé obtient ensuite, depuis un portefeuille d’identités numériques du premier correspondant, le ou les attributs d’identité certifiés demandés. Une fois le ou les attributs obtenus, le procédé les envoie à destination du second terminal et du second correspondant. Ainsi, le second correspondant peut, par exemple dans le cas d’une présentation d’un appel téléphonique, prendre ou non l’appel en fonction de la valeur du ou des attributs d’identité certifiés du premier correspondant reçus.

A noter que le procédé peut être exécuté par un dispositif de fourniture intégré ou connecté au second terminal. Alternativement, le procédé peut être exécuté par un dispositif de fourniture intégré ou connecté au premier terminal. Alternativement, le procédé peut être réparti entre plusieurs terminaux et / ou serveur comme le premier et le second terminal.

On entend par attribut d’identité certifié une ou plusieurs valeurs associées à un élément / champ d’un document d'identité numérique émis par un organisme certifié comme un état ou une entreprise. Un attribut peut par exemple correspondre à un nom de famille, un prénom, une fonction au sein d’une entreprise, une localisation, etc.

On entend par communication électronique, une communication dans laquelle les informations sont transmises à l'aide de signaux produits par des équipements électroniques. Une communication électronique peut par exemple correspondre à une communication de type téléphonique, SMS, MMS, vidéoconférence, messagerie, messagerie instantanée, etc.

A noter que la communication électronique peut faire intervenir une pluralité de correspondants.

On entend par module de communication un module matériel ou logiciel permettant d’établir une communication avec un dispositif tiers.

On entend par portefeuille d’identités numériques un logiciel et/ou un matériel apte à gérer et stocker de manière sécurisée des documents d'identité et des documents officiels (par exemple certifiés par un état ou une entreprise) au format numérique.

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 demande est incluse ou correspond à un message d’un protocole de signalisation permettant l’établissement et le maintien de ladite communication électronique et en ce que l’émission dudit au moins un attribut est réalisée via ledit protocole.

Ce mode de réalisation permet d’utiliser le protocole de signalisation (par exemple SIP ou H323) mis en œuvre lors de l’établissement de la communication électronique entre le premier et le deuxième terminal pour obtenir une demande d’un attribut d’une identité numérique certifiée et pour émettre à destination du demandeur les attributs obtenus depuis un portefeuille d’identités numériques.

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 étape d’obtention est précédée d’une première étape d’émission, à destination dudit deuxième terminal, d’un message indiquant que ledit premier terminal est apte à fournir ledit au moins un attribut.

Ce mode de réalisation permet au premier terminal de déclarer auprès du second terminal, et plus précisément auprès du second utilisateur, que celui-ci est apte à fournir un ou plusieurs attributs d’une identité du premier utilisateur. En d’autres mots, que le premier terminal possède un portefeuille comprenant une ou plusieurs identités numériques du premier utilisateur. Ainsi, le second terminal peut ensuite, par exemple à la demande du second utilisateur, émettre à destination du premier terminal une demande d’un ou de plusieurs attributs d’une identité numérique certifiée du premier utilisateur avec la certitude que la demande aboutira.

Dans le cas d’une communication téléphonique, le message émis par le premier terminal indiquant l’aptitude de celui-ci à fournir un ou plusieurs attributs d’une identité numérique certifié peut, par exemple, correspondre à un message de signalisation de type SIP (Session Initiation Protocol) INVITE ou UPDATE comprenant un paramètre particulier indiquant ladite aptitude (par la suite appelé paramètre d’offre). Le message ou le paramètre d’offre peut en outre comprendre une adresse électronique d’un mandataire logiciel et/ou matériel apte à interagir avec le portefeuille d’identités numérique du premier utilisateur.

Alternativement, le message émis par le premier terminal indiquant les capacités de celui-ci à fournir un ou plusieurs attributs d’une identité numérique certifié peut correspondre à un message spécifique. Dans ce cas, le message peut ne pas inclure de paramètre d’offre et l’information indiquant les capacités du premier terminal à fournir un ou plusieurs attributs d’une identité numérique certifié est alors véhiculée par le message lui-même.

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 étape d’émission est conditionnée par le résultat d’une validation dudit premier utilisateur au niveau d’une interface homme-machine dudit premier terminal.

Ce mode de réalisation permet de proposer au premier utilisateur, via une interface homme-machine restituée par son terminal (premier terminal au sens de l’invention), une option permettant de conditionner l’envoi d’un message indiquant que ledit premier terminal est apte à fournir ledit au moins un attribut par le résultat d’une validation du premier utilisateur. Cette option peut par exemple prendre la forme d’un bouton d’une interface graphique proposant l’envoi du message à destination du second terminal / du second 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 ladite première étape d’émission est précédée d’une première étape de réception d’une demande d’identification dudit premier utilisateur émise par ledit second terminal.

Ce mode de réalisation permet au second terminal et plus particulièrement au second utilisateur de s’assurer que le premier terminal est apte à fournir un ou plusieurs attributs d’une identité numérique certifié du premier utilisateur.

Dans le cas d’une communication téléphonique, la demande d’identification émise par le second terminal à destination du premier terminal peut, par exemple, correspondre à un message de signalisation de type SIP (Session Initiation Protocol) INVITE ou UPDATE comprenant un paramètre particulier indiquant l’objet de la demande (c’est à dire l’identification du premier utilisateur via un ou plusieurs attributs d’une identité numérique certifié du premier utilisateur).

Alternativement, la demande d’identification peut correspondre à un message spécifique. Dans ce cas, le message peut ne pas inclure de paramètre. L’information indiquant la nature de la demande est véhiculée par le message lui-même.

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 étape de réception est conditionnée par le résultat d’une validation dudit second utilisateur au niveau d’une interface homme-machine dudit second terminal.

Ce mode de réalisation permet de proposer au second utilisateur, via une interface homme-machine restituée par son terminal (second terminal au sens de l’invention), une option permettant de conditionner l’envoi d’une demande d’identification dudit premier utilisateur par le résultat d’une validation du second utilisateur. Cette option peut par exemple prendre la forme d’un bouton d’une interface graphique proposant l’envoi du message à destination du premier terminal / du premier 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 ladite demande comprend une requête d’exécution d’un défi cryptographique et en ce que ladite deuxième étape d’obtention comprend :

• une deuxième étape d’émission de ladite demande à destination dudit portefeuille d’identités numériques ;
• une deuxième étape de réception, en fonction du résultat de l’exécution dudit défi cryptographique, dudit au moins un attribut.

Ce mode de réalisation permet une certification par le premier utilisateur des attributs d’identité reçus. Concrètement, une demande d’exécution d’un défi cryptographique est émise à destination du portefeuille d’identité conjointement avec la demande d’attributs. Le défi cryptographique peut par exemple être un défi de type identifiant / mot de passe. Ainsi, avant de fournir les attributs d’identité demandés, le portefeuille d’identités demande au premier utilisateur de valider leur fourniture au second terminal / utilisateur mais également de résoudre le défi cryptographique. Si le premier utilisateur valide la fourniture des attributs d’identité et résout le défi cryptographique alors les attributs obtenus du portefeuille d’identités sont considérés comme certifiés par le premier utilisateur. En outre, le premier utilisateur fournit par là même son consentement à fournir ces informations et valide le fait qu’il est bien le titulaire du portefeuille d’identités et donc des attributs émis.

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 demande est chiffrée.

Ce mode de réalisation permet de sécuriser les échanges entre le portefeuille d’identités numériques et le demandeur (i.e. le second terminal). A noter que le chiffrement de la demande d’attributs peut par exemple être réalisé via une méthode de chiffrement symétrique ou asymétrique.

A noter que les différents modes ou caractéristiques de réalisation précités peuvent être ajoutés indépendamment ou en combinaison les uns avec les autres, au procédé de fourniture défini ci-dessus.

L'invention concerne également un dispositif de fourniture d’au moins un attribut d’au moins une identité numérique certifiée d’un correspondant d’une communication électronique établie ou en cours d’établissement entre au moins un premier terminal d’un premier utilisateur et un second terminal d’un second utilisateur, ledit dispositif étant caractérisé en ce qu’il comprend :

• un premier module d’obtention, d’une demande d’au moins un attribut d’au moins une identité numérique certifiée dudit premier utilisateur, ladite demande étant reçue en provenance d’un module de communication dudit second terminal ;
• un deuxième module d’obtention, depuis un portefeuille d’identités numériques, dudit au moins un attribut ;
• un troisième module d’émission, à destination dudit module de communication, dudit au moins un attribut.

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 terminal comprenant un dispositif de fourniture tel que décrit ci-dessus.

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 de fourniture 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é de fourniture.

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. 1LaFIG. 1illustre un exemple d’environnement de mise en œuvre selon un mode particulier de réalisation de l’invention,

FIG. 2LaFIG. 2illustre l’architecture matérielle d’un dispositif configuré pour mettre en œuvre le procédé de fourniture selon un mode particulier de réalisation de l’invention,

FIG. 3LaFIG. 3illustre des étapes du procédé de fourniture selon un premier mode particulier de réalisation de l’invention.

FIG. 4LaFIG. 4illustre des étapes du procédé de fourniture selon un second mode particulier de réalisation de l’invention.

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

LaFIG. 1illustre un exemple d'environnement de mise en œuvre de l'invention selon un mode particulier de réalisation de l'invention. L'environnement de mise en œuvre comprend un premier terminal 101 d’un utilisateur U1 connecté à un réseau de télécommunications 100, adapté pour établir ou recevoir des communications avec un second terminal 105 d’un utilisateur U2 connecté à un réseau de télécommunications 103 selon l’état de l’art. Les terminaux 101 et 105 sont par exemple des terminaux mobiles, des terminaux fixes, des objets connectés, des assistants vocaux ou tout autre terminal apte à établir et recevoir des communications.

Les réseaux de télécommunications 100 et 103 sont respectivement opérés par les opérateurs de télécommunications des utilisateurs U1 et U2.

Les serveurs 102 et 104 sont des serveurs applicatifs respectivement situés dans les réseaux de télécommunications 100 et 103 aptes à relayer et prendre en charge une communication entre les terminaux 101 et 105.

A noter que l’environnement décrit à l’appui de laFIG. 1est constitué de deux réseaux de télécommunications. Cependant, dans un mode particulier de réalisation de l'invention, les réseaux 100 et 103 peuvent être un seul et même réseau de télécommunications opéré par un seul opérateur de télécommunications. En outre l’environnement peut comprendre plus de deux réseaux de télécommunication et comprendre par exemple un troisième réseau d’interconnexion permettant la communication entre les réseaux 100 et 103.

LaFIG. 2illustre l’architecture matérielle d’un dispositif DISP configuré pour mettre en œuvre le procédé de fourniture selon un mode particulier de réalisation de l’invention. Dans le mode de réalisation décrit ici, ce dispositif a l’architecture matérielle d’un terminal mobile. Il comprend notamment un processeur PROC, une mémoire vive MV, une mémoire morte MEM et une mémoire flash non volatile MF. 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 PROC et sur lequel est enregistré ici un programme informatique PG conforme à l’invention, ce programme comportant des instructions pour mettre en œuvre les étapes du procédé de fourniture tel que décrit précédemment, lorsque le programme est exécuté par le processeur PROC. A l'initialisation, les instructions de code du programme d'ordinateur PG sont par exemple chargées dans une mémoire avant d'être exécutées par le processeur PROC. Le processeur PROC de l'unité de traitement UT met notamment en œuvre les étapes du procédé de fourniture selon l'un quelconque des modes particuliers de réalisation décrits en relation avec les figures 1, 3 et 4, selon les instructions du programme d'ordinateur PG.

Le dispositif DISP comprend également un premier module d’obtention OBT1 apte à obtenir des messages de signalisation d’une communication via par exemple un réseau IP. Le module d’obtention OBT1 est par exemple utilisé pour obtenir, en provenance d’un terminal, par exemple le terminal 105 ou le terminal 101 une demande d’au moins un attribut d’au moins une identité numérique certifiée de l’utilisateur U1.

Le dispositif DISP comprend également un deuxième module d’obtention OBT2 apte à obtenir depuis un portefeuille d’identités numériques un ou plusieurs attributs d’au moins une identité numérique certifiée de l’utilisateur U1.

Selon un mode particulier de réalisation de l'invention, le dispositif DISP peut comprendre un ou plusieurs portefeuilles d’identités numériques (WALL1) de l’utilisateur U1.

Le dispositif DISP comprend en outre un module d’émission SND apte à émettre à destination du dispositif / du terminal qui a émis la demande reçue par le module d’obtention OBT1, un ou plusieurs attributs d’au moins une identité numérique certifiée de l’utilisateur U1.

LaFIG. 3illustre des étapes du procédé de fourniture selon un mode particulier de réalisation de l’invention. LaFIG. 3utilise le même environnement que celui décrit à l’appui de laFIG. 1.

Au cours d’une première étape E10, l’utilisateur U1 initie une communication avec l’utilisateur U2. Plus précisément, le terminal 101 de l’utilisateur U1 émet un message SIP INVITE à destination d’un identifiant de l’utilisateur U2. L’identifiant est, par exemple, un numéro de téléphone (MSISDN), une adresse de messagerie, ou tout autre identifiant permettant à U2 d’être joignable. Le message SIP INVITE envoyé par le terminal 101 à destination d’un identifiant de l’utilisateur U2 est, de façon connue, un message d’initiation d’une communication avec l’utilisateur U2. Une identité de l’utilisateur U1, dite identité non-certifiée, est incluse dans la signalisation d’appel, dans le champ FROM présent dans l’entête du message SIP INVITE. L’identité non-certifiée de l’utilisateur U1 est une identité déclarée par l’utilisateur et/ou le terminal 101 telle qu’un MSISDN, une adresse de messagerie, une adresse IP ou tout autre chaine de caractères et/ou de données binaires.

On note que, de façon connue, les différentes informations placées dans les entêtes du message SIP INVITE appartiennent à ou encore constituent la signalisation de l’appel.

A noter que le protocole de signalisation utilisé pour initier puis établir la communication peut également être le protocole H.323, MGCP, ISUP (ISDN Signalling User Part), BICC (Bearer Independant Call Control), SIP-I (Session Initiation Protocol – ISUP), WebRTC (Web Real Time Communication) ou tout autre protocole de signalisation (par exemple propriétaire) apte à initier / établir une communication. Dans la suite de la description les messages de signalisation échangés entre les terminaux 101 et 105 seront des messages SIP.

Une fois le message SIP INVITE envoyé par le terminal 101, celui-ci est reçu puis pris en charge par le serveur 102 du réseau de télécommunications 100. Sur réception du message SIP INVITE, le serveur 102 peut modifier la signalisation du message, par exemple le champ SIP P-Asserted-Id et/ou modifier l’identité non certifiée déjà présente.

A noter que le serveur 102 peut également modifier d’autres champs de la signalisation du message SIP INVITE comme par exemple le champ SIP PRIVACY dans le cas où l’appelant (U1) a souscrit auprès de son opérateur de télécommunication à un service du type OIR (Originating Identification Restriction) permettant le masquage de son identité lors d’une communication.

Le message SIP INVITE est ensuite envoyé à destination du serveur 104 situé au sein du réseau de télécommunications 103 de l’opérateur de télécommunications de l’utilisateur U2. Suite à la réception du message SIP INVITE par le serveur 104, celui-ci peut modifier la signalisation du message SIP INVITE, par exemple au niveau du paramètre SIP DISPLAY du champ FROM présent dans le message SIP INVITE. Une fois traité par le serveur 104, le message SIP INVITE est ensuite émis à destination du terminal 105.

A l’étape E40, le terminal reçoit et traite le message SIP INVITE puis restitue à l’utilisateur U2, par exemple graphiquement ou vocalement, une identité de l’appelant contenue dans message SIP INVITE, c’est-à-dire une identité de l’utilisateur U1.

De manière connue et suite à ce qui a été décrit précédemment, le terminal peut restituer différentes identités selon sa configuration, la configuration du réseau de l’appelé (U2) et/ou des services souscrits par les utilisateurs U1 et U2 auprès de leur opérateur de télécommunications. Ainsi, le terminal 105 peut restituer à l’utilisateur U2 une identité factice (par exemple renseignée par un pirate), erronée ou altérée (par exemple par un serveur réseau dysfonctionnel). L’identité présentée peut également être une identité dite « technique » comme une chaine de caractère telle qu’un préfixe ou un numéro de téléphone prédéfini, associée à un service de télécommunications.

Pour toutes ces raisons il peut être rassurant pour l’appelé de connaitre / obtenir avec certitude tout ou partie des attributs d’une identité certifiée de son correspondant indépendamment de celle déclarée oralement ou électroniquement. Ainsi, en fonction du ou des attributs d’identité certifiés obtenus, l’appelé peut décider de poursuivre ou non l’établissement de la communication ou la communication en elle-même.

L’initialisation de la communication se poursuit ensuite lors de l’étape E41 lorsque le terminal 105 répond au message SIP INVITE reçu via un message SIP 180 Ringing. Le message SIP 180 Ringing est ensuite reçu par le terminal 101 lors de l’étape E11.

Dans un premier cas de figure nous allons supposer que le terminal de l’utilisateur U1 (101) est apte à fournir un ou plusieurs attributs d’une identité certifiée de l’utilisateur U1. Plus précisément que le terminal 101 exécute, à la demande ou non de l’utilisateur U1, le procédé de fourniture selon l’invention afin de proposer à l’appelé (U2) l’obtention et la vérification par celui-ci de tout ou partie d’une identité certifiée de l’appelant (U1) avant que la communication ne débute. Nous allons également supposer que les échanges permettant la mise en œuvre du procédé de fourniture selon l’invention seront réalisés via l’utilisation du protocole de signalisation SIP. Alternativement, les échanges permettant la mise en œuvre du procédé de fourniture selon l’invention peuvent être réalisés via un protocole propriétaire.

Alternativement le procédé de fourniture selon l’invention est exécuté par le terminal 105 ou un serveur (non représenté).

Alternativement le procédé de fourniture selon l’invention est exécuté de façon répartie entre plusieurs terminaux et ou serveur incluant, par exemple, tout ou partie des terminaux 101 et 105 et des serveurs 102 et 104.

Lors de l’étape E10, le terminal 101 déclare auprès du terminal 105, et plus précisément auprès de l’utilisateur U2, que celui-ci est apte à fournir un ou plusieurs attributs d’une identité certifiée de l’utilisateur U1, c’est-à-dire qu’il possède un portefeuille comprenant une ou plusieurs identités numériques certifiées de l’utilisateur U1. Pour ce faire, le terminal 101 de l’utilisateur U1, plus particulièrement son logiciel de communication DIALL1, peut modifier le message SIP INVITE émis lors de l’étape E10 afin d’y inclure un paramètre (appelé par la suite paramètre d’offre) permettant de déclarer les capacités du terminal 101 à fournir tout ou partie d’une identité certifiée de l’utilisateur U1.

Selon un mode particulier de réalisation, en plus du paramètre d’offre, le message SIP INVITE peut comprendre une adresse électronique d’un mandataire logiciel et/ou matériel (STUB1) apte à interagir avec le portefeuille d’identités numérique certifiées (WALL1) de l’utilisateur U1. A noter que l’adresse électronique du mandataire peut être obtenue préalablement depuis le mandataire lui-même ou pré-provisionné au sein du logiciel de communication DIALL1.

Alternativement ou cumulativement, le paramètre d’offre est inclus dans ou correspond à un message échangé au cours de la communication établie entre les terminaux 101 et 105, par exemple, via un message IP propriétaire ou un message de signalisation SIP UPDATE.

Selon un mode particulier de réalisation, l’émission du paramètre d’offre par le terminal 101 est préalablement validée via une interface homme-machine du terminal 101 par l’utilisateur U1. Cette interface homme-machine peut par exemple prendre la forme d’un composant d'une interface graphique (bouton, case à cocher, etc.) restituée au niveau de l’écran du terminal 101 par le logiciel de communication DIALL1.

Lors de l’étape E40, le terminal 105 reçoit le message de signalisation SIP INVITE et le paramètre d’offre. Le terminal 105 (par exemple le logiciel de communication DIALL2) émet ensuite (E42) une demande d’un ou plusieurs attributs d’une identité certifiée de l’utilisateur U1 à destination du terminal 101.

Selon un mode particulier de réalisation, l’émission de la demande d’un ou plusieurs attributs d’une identité certifiée de l’utilisateur U1 par le terminal 105 (E42) peut être conditionnée par le résultat d’une demande de validation restituée à l’utilisateur U2 via une interface homme-machine de son terminal 105. Cette interface homme-machine peut par exemple prendre la forme d’un composant d'une interface graphique (bouton, case à cocher, etc.) restituée au niveau de l’écran du terminal 105 par le logiciel de communication DIALL2.

A noter que l’utilisateur U2 peut en outre, préalablement à l’envoi par le terminal 105 de la demande d’un ou plusieurs attributs d’une identité certifiée de l’utilisateur U1 (E42), spécifier /choisir le ou les attributs d’identité de l’utilisateur U1 souhaités. Ce choix peut par exemple se faire via une interface homme-machine (graphique ou vocale) du terminal 105.

La demande d’un ou de plusieurs attributs d’une identité certifiée de l’utilisateur U1 est ensuite reçue par le mandataire STUB1 lors de l’étape E32. Dans le cas décrit à l’appui de laFIG. 3, cette demande est reçue par un serveur (par exemple le serveur 102 ou le serveur 104) apte à exécuter la logique applicative du mandataire STUB1.

Alternativement le mandataire STUB1 est exécuté par le terminal 105 ou le terminal 101.

Alternativement, la demande est reçue par le logiciel de communication DIALL1 exécuté par le terminal 101.

Selon un mode particulier de réalisation, le logiciel de communication DIALL1 et le mandataire STUB1 sont une seule et même entité.

Une fois la demande d’attributs reçue en provenance du terminal 105, le mandataire STUB1 la réémet (E33) à destination du portefeuille d’identités numériques certifiées WALL1 de l’utilisateur U1.

Selon un mode particulier de réalisation, le portefeuille d’identités numériques certifiées WALL1 est inclus dans ou associé au terminal 101. Le portefeuille d’identités numériques certifiées peut, par exemple, être inclus dans un élément sécurisé (carte SIM pour Subscriber Identity/Identification Module, eSIM pour embedded SIM, iSIM pour integrated SIM, TEE pour Trusted Execution Environnement, etc.) connecté ou intégré au terminal 101.

Selon un mode particulier de réalisation, la demande d’attributs peut inclure une requête d’exécution d’un défi cryptographique.

Le portefeuille d’identités WALL1 reçoit la demande d’attributs lors de l’étape E23. A l’étape E24, le portefeuille d’identités WALL1 exécute le défi cryptographique lorsque celui-ci est inclus dans la demande d’attributs. Le défi cryptographique est par exemple un défi de type identifiant / mot de passe restitué à l’utilisateur U1 via une interface homme-machine du terminal 101. Ce mode de réalisation permet à l’utilisateur U2 de s’assurer que c’est bien le titulaire du portefeuille d’identités WALL1, c’est-à-dire l’utilisateur U1, qui est à l’origine de l’émission des attributs d’identités de l’utilisateur U1.

Alternativement ou cumulativement, le portefeuille d’identités WALL1 restitue à l’utilisateur U1, via une interface homme-machine du terminal 101, la liste des attributs d’identité demandés (c’est-à-dire le libellé du ou des attributs demandés compris dans la demande d’attributs reçue lors de l’étape E23). Ce mode de réalisation permet à l’utilisateur U1 de prendre connaissance des attributs d’identité demandés et de valider le cas échant leur envoi en totalité ou partiellement.

Lors de l’étape E24, le portefeuille d’identités WALL1 récupère une identité de l’utilisateur U1 (par exemple depuis une mémoire ou d’une base de données interne) puis émet les attributs d’identité de l’utilisateur U1 demandés à destination du mandataire STUB1.

Selon un mode particulier de réalisation, l’exécution de cette étape E24 peut être conditionnée par le résultat du défi cryptographique résolu par l’utilisateur U1.

Selon un mode particulier de réalisation, l’exécution de cette étape E24 peut être conditionnée par le résultat de la validation par l’utilisateur U1 de l’émission des attributs d’identité demandés à destination du terminal 105.

Selon un mode particulier de réalisation, les échanges entre le portefeuille d’identités WALL1 et le mandataire STUB1 sont chiffrés. A noter que le chiffrement peut être mis en œuvre par un algorithme de chiffrement symétrique ou asymétrique selon l’état de l’art.

A l’étape E34 les attributs d’identité sont reçus par le mandataire STUB1 puis réémis (E35) à destination du terminal 105 et plus particulièrement de son logiciel de communication DIALL2.

Une fois les attributs d’identité de l’utilisateur U1 reçus, le terminal 105 peut les restituer (par exemple graphiquement ou vocalement) à l’utilisateur U2 via une interface homme-machine. Ainsi, l’utilisateur a la possibilité de prendre ou non l’appel en fonction des attributs d’identité de l’utilisateur U1 reçus. Si l’utilisateur souhaite prendre l’appel, alors le terminal 105 émet (E46, E16) à destination du terminal 101 un message SIP 200 OK puis reçoit du terminal 101 (E17, E47) un message SIP ACK indiquant que la session RTP, et par conséquent la communication, va débuter.

Avantageusement, ce cas de figure permet à l’appelant de proposer à l’appelé, lors de l’établissement d’appel et avant que la communication ne soit effective (c’est-à-dire avant que l’appelé n’accepte la communication), l’obtention et la vérification par l’appelé d’une identité certifiée de l’appelant.

Dans un deuxième cas de figure nous allons supposer que l’appelé, c’est à dire l’utilisateur U2, souhaite demander explicitement au terminal 101 de l’appelant (U1) l’obtention, pour vérification, de tout ou partie d’une identité certifiée de l’appelant (U1) avant que la communication ne débute.

Le procédé et les avantages restent identiques à ceux exposés pour le premier cas de figure hormis les adaptations décrites ci-après.

Dans ce deuxième cas de figure, le message SIP INVITE émis lors de l’étape E10 correspond à un message SIP INVITE classique selon l’état de l’art (c’est-à-dire un message qui ne comprend pas de paramètre d’offre). Il est reçu par le terminal 105 et plus particulièrement par le logiciel de communication DIALL2 lors de l’étape E40. Lors de l’étape E41, le terminal 105 répond par un message SIP 180 RINGING selon l’état de l’art.

Lors de l’étape E40_1 le terminal 105, sur demande ou non de l’utilisateur U1, émet un message SIP UPDATE qui comprend une demande d’identification de l’utilisateur U1. La demande est par exemple matérialisée par un paramètre particulier inclus dans le message SIP UPDATE. Lors de l’étape E10_1, le message SIP UPDATE est reçu par le terminal 101 et plus particulièrement par le logiciel de communication DIALL1. Lorsque celui-ci détecte la présence de la demande d’identification et qu’il est apte à répondre favorablement à la demande, il émet lors de l’étape E11_1 un message SIP UPDATE comprenant un paramètre d’offre permettant de déclarer les capacités du terminal 101 à fournir tout ou partie d’une identité certifiée de l’utilisateur U1. Il est ensuite reçu par le terminal 105 lors de l’étape E41_1.

Selon un mode particulier de réalisation, en plus du paramètre d’offre, le message SIP UPDATE peut comprendre une adresse électronique du mandataire logiciel et/ou matériel (STUB1) apte à interagir avec le portefeuille d’identités numérique certifiées (WALL1) de l’utilisateur U1. A noter que l’adresse électronique du mandataire peut être obtenue par le logiciel de communication DIALL1 préalablement à l’étape E11_1 depuis le mandataire lui-même ou pré-provisionné au sein de celui-ci.

La suite du procédé reste identique à celui décrit pour le premier cas de figure.

LaFIG. 4illustre des étapes du procédé de fourniture selon un autre mode particulier de réalisation de l’invention. LaFIG. 4utilise le même environnement que celui décrit à l’appui de laFIG. 1.

Au cours d’une première étape E400, l’utilisateur U1 initie une communication avec l’utilisateur U2. Plus précisément, le terminal 101 de l’utilisateur U1 émet à destination du terminal 105 un message SIP INVITE. Le message SIP INVITE émis lors de l’étape E400 est modifié afin d’y inclure une demande d’identification de l’utilisateur U2. La demande est par exemple matérialisée par un paramètre particulier inclus dans le message SIP INVITE.

Lors de l’étape E100, le message SIP INVITE est reçu par le terminal 105 et plus particulièrement par le logiciel de communication DIALL2. Lorsque celui-ci détecte la présence de la demande d’identification et qu’il est apte à répondre favorablement à la demande, il émet lors de l’étape E110 un message SIP 180 Ringing comprenant un paramètre d’offre permettant de déclarer les capacités du terminal 105 à fournir tout ou partie d’une identité certifiée de l’utilisateur U2.

Alternativement, le paramètre d’offre est inclus dans un message SIP UPDATE émis après le message SIP 180 Ringing.

Selon un mode particulier de réalisation, en plus du paramètre d’offre, le message SIP 180 Ringing ou SIP UPDATE peut comprendre une adresse électronique d’un mandataire logiciel et/ou matériel (STUB2) apte à interagir avec le portefeuille d’identités numérique certifiées (WALL2) de l’utilisateur U2. A noter que l’adresse électronique du mandataire STUB2 peut être obtenue préalablement depuis le mandataire lui-même ou pré-provisionné au sein du logiciel de communication DIALL2.

Selon un mode particulier de réalisation, l’émission par le terminal 105 du paramètre d’offre est préalablement validée par l’utilisateur U2 via une interface homme-machine du terminal 105. Cette interface homme-machine peut par exemple prendre la forme d’un composant d'une interface graphique (bouton, case à cocher, etc.) restituée au niveau de l’écran du terminal 105 par le logiciel de communication DIALL2.

Lors de l’étape E410, le terminal 101 reçoit le message de signalisation SIP 180 Ringing et le paramètre d’offre. Le terminal 101 (par exemple le logiciel de communication DIALL1) émet ensuite (E420) une demande d’un ou plusieurs attributs d’une identité certifiée de l’utilisateur U1 à destination du terminal 105.

Selon un mode particulier de réalisation, l’émission de la demande d’un ou plusieurs attributs d’une identité certifiée de l’utilisateur U2 par le terminal 101 (E420) peut être conditionnée par le résultat d’une demande de validation restituée à l’utilisateur U1 via une interface homme-machine de son terminal 101. Cette interface homme-machine peut par exemple prendre la forme d’un composant d'une interface graphique (bouton, case à cocher, etc.) restituée au niveau de l’écran du terminal 101 par le logiciel de communication DIALL1.

A noter que l’utilisateur U1 peut en outre, préalablement à l’envoi par le terminal 101 de la demande d’un ou plusieurs attributs d’une identité certifiée de l’utilisateur U2 (E420), spécifier le ou les attributs d’identité de l’utilisateur U2 souhaités. Ce choix peut par exemple se faire via une interface homme-machine (graphique ou vocale) du terminal 101.

La demande d’un ou de plusieurs attributs d’une identité certifiée de l’utilisateur U2 est ensuite reçue par le mandataire STUB2 lors de l’étape E320. Dans le cas décrit à l’appui de laFIG. 4, cette demande est reçue par un serveur (par exemple le serveur 102 ou le serveur 104) apte à exécuter la logique applicative du mandataire STUB2.

Alternativement le mandataire STUB2 est exécuté par le terminal 101 ou le terminal 105.

Alternativement, la demande est reçue par le logiciel de communication DIALL2 exécuté par le terminal 105.

Selon un mode particulier de réalisation, le logiciel de communication DIALL2 et le mandataire STUB2 sont une seule et même entité.

Une fois la demande d’attributs reçue en provenance du terminal 101, le mandataire STUB2 la réémet (E330) à destination du portefeuille d’identités numériques certifiées WALL2 de l’utilisateur U2.

Selon un mode particulier de réalisation, le portefeuille d’identités numériques certifiées WALL2 est inclus dans ou associé au terminal 101. Le portefeuille d’identités numériques certifiées peut, par exemple, être inclus dans un élément sécurisé (carte SIM pour Subscriber Identity/Identification Module, eSIM pour embedded SIM, iSIM pour integrated SIM, TEE pour Trusted Execution Environnement, etc.) connecté ou intégré au terminal 101.

Selon un mode particulier de réalisation, la demande d’attributs peut inclure une requête d’exécution d’un défi cryptographique.

Le portefeuille d’identités WALL2 reçoit la demande d’attributs lors de l’étape E230. A l’étape E240, le portefeuille d’identités WALL2 exécute le défi cryptographique lorsque celui-ci est inclus dans la demande d’attributs. Le défi cryptographique est par exemple un défi de type identifiant / mot de passe restitué à l’utilisateur U2 via une interface homme-machine du terminal 105. Ce mode de réalisation permet à l’utilisateur U1 de s’assurer que c’est bien le titulaire du portefeuille d’identités WALL2, c’est-à-dire l’utilisateur U2, qui est à l’origine de l’émission des attributs d’identités de l’utilisateur U2.

Alternativement ou cumulativement, le portefeuille d’identités WALL2 restitue à l’utilisateur U2, via une interface homme-machine du terminal 105, la liste des attributs d’identité demandés (c’est-à-dire le libellé du ou des attributs demandés compris dans la demande d’attributs reçue lors de l’étape E230). Ce mode de réalisation permet à l’utilisateur U2 de prendre connaissance des attributs d’identité demandés et de valider le cas échant leur envoi partiellement ou en totalité.

Lors de l’étape E240, le portefeuille d’identités WALL2 récupère une identité de l’utilisateur U2 (par exemple depuis une mémoire ou d’une base de données interne) puis émet les attributs d’identité de l’utilisateur U2 demandés à destination du mandataire STUB2.

Selon un mode particulier de réalisation, l’exécution de cette étape E240 peut être conditionnée par le résultat du défi cryptographique résolu par l’utilisateur U2.

Selon un mode particulier de réalisation, l’exécution de cette étape E240 peut être conditionnée par le résultat de la validation par l’utilisateur U2 de l’émission des attributs d’identité demandés à destination du terminal 101.

Selon un mode particulier de réalisation, les échanges entre le portefeuille d’identités WALL2 et le mandataire STUB2 sont chiffrés. A noter que le chiffrement peut être mis en œuvre par un algorithme de chiffrement symétrique ou asymétrique selon l’état de l’art.

A l’étape E340 les attributs d’identité sont reçus par le mandataire STUB2 puis réémis (E350) à destination du terminal 101 et plus particulièrement de son logiciel de communication DIALL1 (reçus lors de l’étape E450).

Une fois les attributs d’identité de l’utilisateur U2 reçus, le terminal 101 peut les restituer (par exemple graphiquement ou vocalement) à l’utilisateur U1 via une interface homme-machine. Ensuite, le terminal 101 émet (E460, E160) à destination du terminal 105 un message SIP 200 OK puis reçoit (E170, E470) du terminal 105 un message SIP ACK indiquant que la session RTP, et par conséquent la communication, va débuter.

Claims (1)

1. Support d'informations lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur apte à mettre en œuvre des étapes d’un procédé de fourniture d’au moins un attribut d’au moins une identité numérique certifiée d’un correspondant d’une communication électronique établie ou en cours d’établissement entre au moins un premier terminal (101) d’un premier utilisateur (U1) et un second terminal (105) d’un second utilisateur (U2) lorsque ledit programme est exécuté par un processeur, ledit procédé comprenant les étapes suivantes :
   - une première étape d’obtention (E32), d’une demande d’au moins un attribut d’au moins une identité numérique certifiée dudit premier utilisateur, ladite demande étant reçue en provenance d’un module de communication dudit second terminal ;
   - une deuxième étape d’obtention (E34), depuis un portefeuille d’identités numériques (WALL1), dudit au moins un attribut ;
   - une troisième étape d’émission (E35), à destination dudit module de communication, dudit au moins un attribut.