Login| Sign Up| Help| Contact|

Patent Searching and Data


Title:
METHOD FOR CONNECTING TO A VIDEOCONFERENCE MADE SECURE BY STRONG AUTHENTICATION
Document Type and Number:
WIPO Patent Application WO/2022/038096
Kind Code:
A1
Abstract:
The present invention mainly relates to a method for achieving a secure connection to a platform (P_vis) enabling a videoconference between a plurality of participants (P1-Pn, I1-Im) and that guarantees the identity of the participants (P1-Pn, I1-Im) via strong authentication, characterised in that it hinges about two phases: an organisation phase and a connection phase. The invention especially makes it possible to guarantee that only the intended recipient of the invite is able to decrypt the latter and to access the meeting room to which he has been invited. When he connects, each participant (P1-Pn, I1-Im) in the meeting appears under the name corresponding to the individual complex invite link such as defined beforehand by the organiser. The spelling of this name is, in addition, made unalterable via use of a hash function, insofar as it could not be modified by the invited participant, nor recreated and usurped by anyone. Thus, the system and all the participants (P1-Pn, I1-Im) are absolutely certain of the identity of the person who has connected to a meeting using this method.

Inventors:
ROSSI JEAN-YVES (FR)
LUU DUY-TUNG (FR)
RENIER JULES (FR)
Application Number:
PCT/EP2021/072749
Publication Date:
February 24, 2022
Filing Date:
August 16, 2021
Export Citation:
Click for automatic bibliography generation   Help
Assignee:
CANTON CONSULTING (FR)
International Classes:
G06F21/62; H04L12/18
Foreign References:
US20140095871A12014-04-03
US9635072B12017-04-25
EP3438836A12019-02-06
US20180351757A12018-12-06
Attorney, Agent or Firm:
MARCONNET, Sébastien (FR)
Download PDF:
Claims:
REVENDICATIONS Procédé de connexion sécurisé à une plateforme de visio-conférence (P_vis) entre plusieurs participants (P1 -Pn, 11 -Im) garantissant l’identité des participants par authentification forte caractérisé en ce qu'il est articulé autour de deux phases: l’une d’organisation, l’autre de connexion:

• la phase d’organisation comportant:

- une étape de définition de caractéristiques d'une réunion, tels qu'un horaire de début et de fin, une salle virtuelle de réunion, un thème ou un agenda, et le cas échéant des paramètres de contexte, comme par exemple le fuseau horaire, la langue d’échange, les documents support, les conditions légales applicables à la réunion, etc..

- une étape de définition d'une liste de participants dont les identités sont prédéfinies, soit par référence à un répertoire existant dans le cas d'une convocation pour un participant connu (P1 -Pn) soit par initiation d’un processus d’association dans ce répertoire d’une personne nouvelle connue par divers moyens tels que son adresse mail ou son téléphone (enrôlement), soit en prévoyant une étape d’authentification forte préalable à l’interconnexion, par tout procédé géré par un serveur d’authentification à cet effet, comme un mot de passe à usage unique, pour des personnes qui n’ont pas vocation à être enregistrées dans ce répertoire (invitation) pour un participant de type invité (11 -Im),

- une étape de génération, pour chaque participant (P1 -Pn, 11 -Im) à la réunion, d'un lien d'invitation complexe individuel (LICI) vers la réunion, ledit lien d'invitation complexe individuel (LICI) prenant la forme d’un jeton JSON Web Token tel que défini par un rfc de l’IETF, dont une charge utile contient des informations relatives aux caractéristiques et le cas échéant aux paramètres de contexte de la réunion ainsi que des informations relatives à l'identité de chaque participant (P1 -Pn, 11 -Im) auquel est destiné ledit lien d'invitation complexe individuel (LICI), le jeton étant généré de façon à garantir l’intégrité des données contenues dans son entête et dans sa charge utile, le tout étant signé numériquement avec une fonction de hashage choisie pour assurer un haut niveau de sécurité de l’encodage et dont une clé secrète est conservée sur un serveur d'interconnexion (SJnt) ou, le cas échéant, sur un serveur d'authentification (S_auth) distinct du serveur d'interconnexion (SJnt),

- une étape de génération à partir de ces liens d’invitation complexe individuels, d’un alias de chaque lien d’invitation complexe individuel (ALICI) lequel alias est le produit d’une fonction de hashage apte à générer une empreinte numérique à partir du lien d’invitation complexe individuel (LICI), ladite empreinte numérique étant unique pour chaque lien d’invitation complexe individuel (LICI), conformément aux caractéristiques de la fonction de hashage et n’offrant aucune possibilité de reconstituer le lien complexe original sans disposer d'une clé privée conservée de manière sécurisée sur le serveur d'interconnexion (SJnt) ou le cas échéant, le serveur d'authentification (S_auth),

- une étape d’envoi, par mail, de chaque alias de lien d'invitation complexe individuel (ALICI) au participant (P1 -Pn, 11 -Im) correspondant sous forme d’un lien hypertexte court,

- une étape de sauvegarde ou d’envoi vers le serveur d'interconnexion (SJnt) ou le cas échéant vers le serveur d'authentification (S_auth), d'un mécanisme de correspondance entre les alias des liens d'invitation complexes (ALICI) et les liens d'invitation complexes individuels (LICI),

• puis la phase de connexion comportant:

- une étape dans laquelle le participant (P1 -Pn, 11 -Im) en possession du lien court l’utilise pour se connecter à un domaine correspondant, qui est un domaine hébergeant un serveur d'authentification (S_auth) dans le cadre d'un flux de connexion a) ou le cas échéant un serveur d'interconnexion (SJnt) qui utilise le serveur d'authentification (S_auth) comme un partenaire de confiance dans le cas d'un flux de connexion b),

- dans le flux de connexion a), une étape dans laquelle le serveur d'authentification (S_auth) requiert du participant (P1 -Pn, 11 -Im) qui se connecte une authentification forte selon un procédé de type standard, un déroulement de ladite authentification étant immédiat dans le cas d’une personne connue ou bien qui passera par une phase d’enrôlement ou d’identification par authentification forte gérée par le serveur d'authentification, 18 par tout procédé disponible comme l’usage d’un mot de passe à usage unique, dans le cas d’une personne invitée,

- dans le flux de connexion b), une étape dans laquelle le serveur d'interconnexion (SJnt) sollicite le serveur d'authentification (S_auth) à l'égard de qui il est partenaire de confiance, lequel serveur d'authentification (S_auth) requiert du participant (P1 -Pn, 11 -Im) qui se connecte une authentification forte selon un procédé de type standard, un déroulement de ladite authentification étant immédiat dans le cas d’un lien de convocation et dont le déroulement sera immédiat dans le cas d’une personne connue ou bien qui passera par une phase d’enrôlement ou d’identification par authentification forte gérée par le serveur d'authentification forte, par tout procédé disponible comme l’usage d’un mot de passe à usage unique, dans le cas d’une personne invitée,

- une étape dans laquelle, si l’authentification forte échoue, le processus d'interconnexion s’interrompt, et si l’authentification est réussie, le serveur d'authentification (S_auth) transmet au serveur d'interconnexion (SJnt) l’alias de lien d'invitation complexe individuel (ALICI) reçu dans le cas du flux de connexion flux a) ou bien, dans le cas du flux de connexion b) une information que l'authentification forte a bien été accomplie et que l'alias de lien d'invitation complexe individuel (ALICI) peut être traité, ledit alias de lien d'invitation complexe individuel (ALICI) reçu par l'un ou l'autre flux a) ou b) étant alors converti en lien d’invitation complexe individuel (LICI) correspondant et ce dernier lien permettant au serveur d'interconnexion (SJnt) d’introduire l’utilisateur qui a réussi le challenge d'authentification forte, déclenchant ainsi l’utilisation du jeton, contenant et révélant les caractéristiques de la réunion et le cas échéant les paramètres de contexte, pour initier la connexion du participant authentifié (P1 -Pn, 11 -Im),

- une étape de connexion du participant authentifié (P1 -Pn, 11 -Im) à la visioconférence s’effectuant conformément aux informations du lien d'invitation complexe individuel (LICI), notamment l’identité de la personne correspondante, transmis au serveur d'interconnexion (SJnt) à l’issue de l’étape d’authentification forte, laquelle est une condition absolument nécessaire de la lecture des informations du lien d'invitation complexe individuel (LICI), 19

- une étape d’utilisation du terminal du participant (P1 -Pn, 11 -Im) pour participer à la visio-conférence au travers d’une couche de transport réseau sécurisée assurant une transmission d'information vers et depuis une plateforme de visio-conférence P_vis. Procédé selon la revendication 1 , caractérisé en ce que l'empreinte numérique prend notamment la forme d’une chaîne de caractères UTF-8. Procédé selon la revendication 1 ou 2, caractérisé en ce que le mécanisme de correspondance entre les alias des liens d'invitation complexes ALICI et les liens d'invitation complexes individuels LICI prend la forme d'une table ou le cas échéant d'éléments cryptographiques sécurisés permettant d’assurer cette correspondance. Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce que la fonction de hashage est de type SHA ou de type ECDSA. Procédé selon l'une quelconque des revendications 1 à 4, caractérisé en ce que le serveur d'authentification (S_auth) requiert du participant (P1-Pn, 11 -Im) qui se connecte une authentification forte selon un procédé défini par le standard du W3C WebAuthn, ou tout autre procédé équivalent. Procédé selon l'une quelconque des revendications 1 à 5, caractérisé en ce que la connexion du participant authentifié (P1 -Pn, 11 -Im) à la visio-conférence est opérée au travers de protocoles internet standard de type UDP et/ou TURN. Procédé selon l'une quelconque des revendications 1 à 6, caractérisé en ce que la couche de transport réseau sécurisée est un protocole de type TLS. Procédé selon l'une quelconque des revendications 1 à 7, caractérisé en ce que le terminal du participant (P1 -Pn, 11 -Im) communique avec la plateforme de visio-conférence (P_vis) opérant selon un standard, tel qu'un standard de type WebRTC. 20 Procédé selon l'une quelconque des revendications 1 à 8, caractérisé en ce qu'il comporte une étape d’utilisation d'une interface logicielle (10) pour la définition des paramètres de la réunion. Procédé selon la revendication 9, caractérisé en ce que l'interface logicielle (10) met en oeuvre des boutons (B1 , B2) de génération et d'envoi de liens courts d'invitation à destination des différents participants (P1 -Pn, 11 -Im). Procédé selon l’une quelconque des revendications 1 à 10, caractérisé en ce qu'il comporte une étape de désignation d'un ou plusieurs modérateurs ayant la possibilité de contrôler des droits pour les différents participants (P1 -Pn, 11 - Im), tels que le droit de parler ou le droit de partager un document ou d’enregistrer la conférence ou bien au contraire d’en interdire l’enregistrement. Procédé selon l'une quelconque des revendications 1 à 1 1 , caractérisé en ce que la sélection des participants (P1 -Pn, 11 -Im) et/ou une sélection d'un nom de salle (R) est effectuée au moyen d'une liste déroulante (Ld).

Description:
DESCRIPTION

TITRE : PROCÉDÉ DE CONNEXION À UNE VISIOCONFÉRENCE SÉCURISÉE PAR AUTHENTIFICATION FORTE

[001]La présente invention porte sur un procédé de connexion à une visioconférence sécurisée par une authentification forte. L'invention vise à sécuriser et garantir l'identité des participants et des invités dans l'emploi d'une technologie de visio-conférence sur le web selon une architecture ouverte qui permet de dissocier les services d’identification par authentification forte, de visio-conférence et d’interconnexion entre les deux précédents.

[002]On connaît des plateformes de visio-conférence permettant d'inviter des participants à une réunion virtuelle définie notamment par un horaire de début et de fin ainsi qu'un thème ou un agenda caractéristique. Dans le cadre de la visioconférence, les participants peuvent alors communiquer entre eux via des moyens de communication audio et vidéo de leur terminal de connexion prenant la forme d'un ordinateur ou d'un téléphone portable de type "smartphone".

[003]En général, un lien d'invitation unique, sous forme de lien de type URL, est envoyé à toutes les personnes conviées à la réunion. Après la sélection du lien, chaque personne peut alors se connecter à la réunion correspondante en indiquant son identité. Il n'existe en règle générale aucun contrôle sur la manière dont chaque participant pourra choisir de se définir. En conséquence, de multiples incertitudes existent sur l’identité des participants et en particulier toute personne qui intercepte le lien d'invitation peut assister à la réunion en usurpant un nom quelconque voire le nom de l'invité. Certains systèmes dotés par eux-mêmes d’une étape de connexion peuvent imposer une identification pour accéder à l’interface de web- conférence mais cette étape repose sur une identité initiale déclarative introduite à l’entrée dans le système et cette étape ne fait donc que vérifier la réitération de cette affirmation initiale, invérifiable en elle-même.

[004]Cela est problématique dans le cas où un participant n'est pas connu des autres participants, ou si un problème de caméra ou de réseau, réel ou provoqué,

FEUILLE DE REMPLACEMENT (RÈGLE 26) empêche les autres participants de voir et vérifier son visage. Les systèmes existants rendent donc également possible les fraudes ou détournements consistant à utiliser des logiciels d'intelligence artificielle très performants pour déformer le signal audio d'une voix afin de réaliser en temps réel des imitations de voix ou d’apparence de visage.

[005] L'invention vise à remédier efficacement aux inconvénients précités en proposant un procédé de connexion sécurisé à une plateforme de visio-conférence entre plusieurs participants garantissant l’identité des participants par authentification forte et, à cette fin, articulé autour de deux phases: l’une d’organisation, l’autre de connexion:

• la phase d’organisation comportant:

- une étape de définition de caractéristiques d'une réunion, tels qu'un horaire de début et de fin, une salle virtuelle de réunion, un thème ou un agenda, et le cas échéant des paramètres de contexte, comme par exemple le fuseau horaire, la langue d’échange, les documents supports, les conditions légales applicables à la réunion, etc.

- une étape de définition d'une liste de participants dont les identités sont prédéfinies, soit par référence à un répertoire existant (convocation) soit par initiation d’un processus d’association dans ce répertoire d’une personne nouvelle connue par divers moyens tels que son adresse mail, son téléphone, etc (enrôlement), soit en prévoyant une étape d’authentification forte préalable à l’interconnexion, par tout procédé géré par le serveur d’authentification forte à cet effet, comme un mot de passe à usage unique, pour des personnes qui n’ont pas vocation à être enregistrées dans ce répertoire (invitation),

- une étape de génération, pour chaque participant à la réunion, d'un lien d'invitation complexe individuel (LICI) vers la réunion, ledit lien d'invitation complexe individuel (LICI) prenant la forme d’un jeton (ou "token" en anglais), JSON Web Token tel que défini par un rfc de l’IETF, dont une charge utile ("payload" en anglais) contient des informations relatives aux caractéristiques et le cas échéant aux paramètres de contexte de la réunion ainsi que des informations relatives à l'identité de chaque participant auquel est destiné ledit lien d'invitation complexe individuel (LICI), le jeton étant généré de façon à garantir l’intégrité des données contenues dans son entête (ou "header" en anglais) et dans sa charge utile, le tout étant signé numériquement avec une fonction de hashage choisie pour assurer un haut niveau de sécurité de l’encodage et dont une clé secrète est conservée sur un serveur d’interconnexion ou, le cas échéant, sur un serveur d'authentification distinct du serveur d’interconnexion,

- une étape de génération à partir de ces liens d’invitation complexe individuels, d’un alias de chaque lien d’invitation complexe (ALICI) lequel alias est le produit d’une fonction de hashage apte à générer une empreinte numérique à partir du lien d’invitation complexe individuel (LICI), notamment sous forme d’une chaîne de caractères UTF-8, ladite empreinte numérique étant unique pour chaque lien d’invitation complexe (LICI), conformément aux caractéristiques de la fonction de hashage et n’offrant aucune possibilité de reconstituer le lien complexe original sans disposer d'une clé privée conservée de manière sécurisée sur le serveur d’interconnexion ou le cas échéant, le serveur d'authentification,

- une étape d’envoi, par mail, de chaque alias de lien d'invitation complexe individuel (ALICI) au participant correspondant sous forme d’un lien hypertexte court,

- une étape de sauvegarde ou d’envoi vers le serveur d’interconnexion ou le cas échéant vers le serveur d'authentification, d'un mécanisme de correspondance entre les alias des liens d'invitation complexes (ALICI) et les liens d'invitation complexes individuels (LICI),

• puis la phase de connexion comportant:

- une étape dans laquelle le participant en possession du lien court l’utilise pour se connecter à un domaine correspondant, qui est un domaine hébergeant un serveur d’authentification dans le cadre d'un flux de connexion a) ou le cas échéant un serveur d'interconnexion qui utilise le serveur d'authentification comme partenaire de confiance ("Relying Party" en anglais) dans le cas d'un flux de connexion b

- dans le flux de connexion a), une étape dans laquelle le serveur d’authentification requiert du participant qui se connecte une authentification forte selon un procédé défini par le standard du W3C ‘WebAuthn’ ou tout autre procédé équivalent, un déroulement de ladite authentification étant immédiat dans le cas d’une personne connue ou bien qui passera par une phase d’enrôlement ou d’identification par authentification forte gérée par le serveur d'authentification, par tout procédé disponible comme l’usage d’un mot de passe à usage unique, dans le cas d’une personne invitée,

- dans le flux de connexion b), une étape dans laquelle le serveur d'interconnexion sollicite le serveur d’authentification à l'égard de qui il est partenaire de confiance, lequel serveur d'authentification requiert du participant qui se connecte une authentification forte selon un procédé défini par le standard WebAuthn du W3C ou tout autre procédé équivalent, un déroulement de ladite authentification étant immédiat dans le cas d’un lien de convocation et dont le déroulement sera immédiat dans le cas d’une personne connue ou bien qui passera par une phase d’enrôlement ou d’identification par authentification forte gérée par le serveur d'authentification forte, par tout procédé disponible comme l’usage d’un mot de passe à usage unique, dans le cas d’une personne invitée,

- une étape dans laquelle, si l’authentification forte échoue, le processus d’interconnexion s’interrompt, et si l’authentification est réussie, le serveur d’authentification transmet au serveur d’interconnexion l’alias de lien d'invitation complexe individuel (ALICI) reçu (flux a) ou bien (flux b) une information que l'authentification forte a bien été accomplie et que l'alias de lien d'invitation complexe individuel (ALICI) peut être traité, ledit alias de lien d'invitation complexe individuel (ALICI) reçu par l'un ou l'autre flux étant alors converti en lien d’invitation complexe individuel (LICI) correspondant et ce dernier lien permettant au serveur d’interconnexion d’introduire l’utilisateur qui a réussi le challenge d'authentification forte, déclenchant ainsi l’utilisation du jeton, contenant et révélant les caractéristiques de la réunion et le cas échéant les paramètres de contexte, pour initier la connexion du participant authentifié,

- une étape de connexion du participant authentifié à la visio-conférence, cette connexion opérée au travers des protocoles internet standard (UDP et ou TURN) ou de tout autre protocole internet de connexion avec le navigateur du participant ainsi authentifié équivalent, s’effectuant conformément aux informations du lien d'invitation complexe individuel (LICI), notamment l’identité de la personne correspondante, transmis au serveur d’interconnexion à l’issue de l’étape d’authentification forte, laquelle est la condition absolument nécessaire de la lecture des informations du lien d'invitation complexe individuel (LICI), - une étape d’utilisation du terminal du participant pour participer à la visioconférence au travers d’une couche de transport réseau sécurisée (TLS) ou de tout autre protocole équivalent assurant la transmission vers et depuis la plateforme de visio-conférence opérant selon un standard, tel qu'un standard de type WebRTC ou tout autre procédé équivalent.

[006] Il est précisé que le terme d’authentification forte doit être interprété en référence à cette notion dans le domaine de la sécurité des systèmes d'information, "une procédure d’identification qui requiert la concaténation d’au moins deux facteurs d’authentification", (https://fr.wikipedia.org/wiki/Authentification_forte). Il sera aussi observé que la Directive 2016/866/UE donne en son article 4 la définition suivante:

[007] "30) «authentification forte du client», une authentification reposant sur l’utilisation de deux éléments ou plus appartenant aux catégories «connaissance» (quelque chose que seul l’utilisateur connaît), «possession» (quelque chose que seul l’utilisateur possède) et «inhérence» (quelque chose que l’utilisateur est) et indépendants en ce sens que la compromission de l’un ne remet pas en question la fiabilité des autres, et qui est conçue de manière à protéger la confidentialité des données d’authentification; "

[008]Comme on le voit, l'authentification forte se distingue d'une authentification ordinaire par le fait de combiner deux facteurs parmi trois: ce que l'on sait, ce que l'on possède ou ce que l'on est.

[009] L’invention permet ainsi de garantir que seul le destinataire de l'invitation peut décrypter cette dernière et accéder à la salle de réunion à laquelle il a été invité. Lorsqu’il se connecte, chaque participant à la réunion apparaît sous le nom correspondant au lien d'invitation complexe individuel, tel que prédéfini par l'organisateur. Ce libellé de nom est, de plus, rendu inaltérable par l’utilisation de la fonction de hashage, dans la mesure où il ne peut pas être modifié par l'invité, ni recréé et usurpé par quiconque. Ainsi, tous les participants sont absolument certains de l’identité de la personne qui s'est connectée à une réunion par ce procédé. [0010] Grâce à l'invention, l'invité, et lui seul, peut déclencher la conversion de l’alias d'invitation complexe individuel en un lien d'invitation complexe individuel (lequel est le seul révélant les caractéristiques de la réunion et permettant de s’y connecter) et le décryptage dudit jeton (ou "token") va seul permettre d’entraîner la connexion sur la salle de réunion, selon les horaire et thème définis par l'organisateur, entraînant l'entrée en conférence de la personne identifiée, affichée sous son nom, tel que ce nom a été défini par l'organisateur mais aussi dont la réalité effective est garantie par le succès de l'opération d'authentification qui est une condition nécessaire au décryptage du lien d'invitation complexe individuel.

[0011] En outre, étant donné que le procédé définit des paramètres de réunion, une liste de participants ainsi qu'une politique de sécurité, il sera possible d’alerter si plusieurs personnes ayant le même nom se connectent sous des adresses différentes, ou si des invités utilisent une connexion qui n'a pas été sécurisée ou de toute autre anomalie ou incohérence. La définition du périmètre de la réunion par l'ensemble de ces paramètres réunit ainsi les conditions nécessaires et suffisantes pour que des programmes de contrôle puissent vérifier le bon déroulement de la réunion tel que l'organisateur l'avait prévu.

[0012] Selon une mise en oeuvre de l'invention, ledit procédé comporte une étape d’utilisation d'une interface logicielle pour la définition des paramètres de la réunion.

[0013] Selon une mise en oeuvre de l'invention, l'interface logicielle met en oeuvre des boutons de génération et d'envoi de liens courts d'invitation à destination des différents participants.

[0014] Selon une mise en oeuvre de l'invention, ledit procédé comporte une étape de désignation d'un ou plusieurs modérateurs ayant la possibilité de contrôler des droits pour les différents participants, tels que le droit de parler ou le droit de partager un document ou d’enregistrer la conférence ou bien au contraire d’en interdire l’enregistrement.

[0015] Selon une mise en oeuvre de l'invention, la sélection des participants et/ou une sélection d'un nom de salle est effectuée au moyen d'une liste déroulante. [0016] La présente invention sera mieux comprise et d’autres caractéristiques et avantages apparaîtront encore à la lecture de la description détaillée qui suit comprenant des modes de réalisation donnés à titre illustratif en référence avec les figures annexées, présentés à titre d’exemples non limitatifs, qui pourront servir à compléter la compréhension de la présente invention et l’exposé de sa réalisation et, le cas échéant, contribuer à sa définition, sur lesquelles:

[0017] [Fig. 1 ] La figure 1 montre un exemple d'interface logicielle de création de réunion mis en oeuvre par la présente invention permettant de définir les différents paramètres d'une réunion de visio-conférence;

[0018] [Fig. 2a] La figure 2a est un diagramme fonctionnel d'un système informatique mettant en oeuvre le procédé de connexion sécurisé à une visioconférence selon la présente invention;

[0019] [Fig. 2b] La figure 2b est un diagramme fonctionnel d'un système informatique mettant en oeuvre une variante du procédé de connexion sécurisé à une visio-conférence selon la présente invention;

[0020] [Fig. 3] La figure 3 est une illustration d'une liste déroulante pouvant être utilisée dans le cadre du procédé selon l'invention pour la sélection de participants connus;

[0021] [Fig. 4] La figure 4 montre un exemple de fenêtre d'authentification pouvant être utilisée dans le cadre du procédé selon l'invention;

[0022] [Fig. 5] La figure 5 montre un exemple de fenêtre de vérification d'identité pouvant être utilisée suite à l'envoi d'un code vers une adresse email ou un numéro de téléphone d'un participant.

[0023] Il est à noter que, sur les figures, les éléments fonctionnels communs aux différents modes de réalisation présentent les mêmes références.

[0024] La figure 1 montre une interface logicielle 10 permettant à un organisateur de définir des caractéristiques d'une réunion, notamment un horaire, un nom de salle, un thème ou un ordre du jour et le cas échéant des paramètres de contexte tels que le nom des participants, le nom des organisateurs et modérateurs, les références d’une salle physique où la conférence sera visible et où les personnes physiquement présentes pourront se regrouper pour participer, le fuseau horaire, la langue d’échange, les documents supports, les conditions légales applicables à la réunion, etc.. Un organisateur ou un ou des modérateurs pourront assurer une gestion de salles de réunion accessibles ainsi que créer, modifier, supprimer, ou programmer chaque réunion sur laquelle il disposera de tels droits.

[0025] On définit également une liste de participants P1 -Pn, 11 -Im dont les identités sont prédéfinies. La liste des participants pourra être définie soit par référence à un répertoire existant dans le cadre d'une convocation pour les participants connus (P1 -Pm) soit par initiation d’un processus d’association dans ce répertoire d’une personne nouvelle connue par divers moyens tels que son adresse mail, son téléphone, etc (enrôlement) ou d’identification par authentification forte gérée par le serveur d'authentification correspondant, par tout procédé disponible comme l’usage d’un mot de passe à usage unique (invitation) pour les participants de type invités (11 -Im). Il est alors possible de désigner un ou plusieurs modérateurs ayant la possibilité de contrôler des droits pour les différents participants P1 -Pn, 11 - Im, tels que le droit de parler ou le droit de partager un document. Le ou les modérateurs pourront également contrôler le droit d'enregistrer la conférence ou bien au contraire d’en interdire l’enregistrement.

[0026] Comme cela est illustré par la figure 3, la sélection des participants P1 - Pn, 11 -Im pourra être effectuée au moyen d'une liste déroulante Ld. Une liste déroulante du même type pourra être utilisée pour sélectionner le nom de la salle R souhaitée. Alternativement, il est possible de créer un nouveau nom de salle R pour une réunion particulière.

[0027] Il est également possible de créer une date de début associée à une heure de début via les champs C1 et C2 et une date d'expiration associée à une heure d'expiration de la réunion via les champs C3 et C4. Ces horaires peuvent aussi être définis en référence à l’UTC et aux divers fuseaux horaires des participants P1 -Pn, 11 -Im. [0028] L'organisateur pourra générer des liens d'invitations pour un participant P1 -Pn, 11 -Im, pour un groupe, pour un service, pour une diffusion vers le public, via l'appui sur un bouton de commande. Dans l'exemple représenté, un bouton de commande B1 , B2 est associé à chaque participant P1 -Pn, 11 -Im mais il est possible d’ajouter un bouton de génération de liens d'invitation commun à tous les participants P1 -Pn, 11 -Im suite à une validation de la réunion.

[0029] Comme cela est décrit plus en détails ci-après, on pourra distinguer des participants P1 -Pn, 11 -Im connus du système (typiquement les employés d'une entreprise ou d'une organisation ou les clients d'une société ou d'un prestataire de services) et des participants 11 -Im de type “invité” inconnus du système. Pour les participants connus P1 -Pn, un niveau d'authentification élevé pourra être mise en oeuvre, dans la mesure où un ou plusieurs facteurs d'authentification relatifs aux participants P1 -Pn auront pu être préalablement enregistrés dans le système. Pour les participants 11 -Im de type "invité", un niveau d'authentification inférieur pourra être mis en oeuvre basé uniquement sur un numéro de téléphone et/ou une adresse email du participant 11 -Im. Dans ce cas une forme d’authentification forte peut être obtenue par l’envoi d’un mot de passe à usage unique (OTP) par SMS, que l’utilisateur recevra lorsqu’il se connectera via son alias de lien d'invitation complexe individuel (ALICI décrit plus en détails ci-après) puis qu’il devra entrer lorsqu’il lui sera demandé pour accéder à une page d’enrôlement, établissant ainsi être bien en possession du téléphone correspondant à celui de l’invité, tel qu’il était antérieurement connu par l’invitant.

[0030] Un organisateur pourra également effectuer un suivi de réunions via la conservation et, le cas échéant, la transmission aux différents participants P1 -Pn, 11 -Im d'un compte-rendu de réunion. Cette transmission de compte-rendu pourra être automatisée. L'organisateur pourra également conserver un historique des comptes-rendus de réunions antérieures.

[0031] Comme cela est illustré par la figure 2a, le procédé est mis en oeuvre par un système informatique comportant notamment un serveur de génération de liens d'invitation S_gen associé à une base de données BDD, un serveur d'authentification S_auth, un serveur d'interconnexion S_int, et une plateforme de visio-conférence P_vis. Le serveur d'authentification S_auth et le serveur d'interconnexion S_int peuvent être installés conjointement ou séparément mais alors reliés par une relation de confiance de type partenaire de confiance ("Relying party" en anglais). Le serveur d'interconnexion S_int se repose alors sur le serveur d'authentification S_auth pour effectuer l'authentification des participants P1 -Pn, 11 - Im. Autrement dit, l'opération d'authentification est sous-traitée au serveur d'authentification S_auth par le serveur d'interconnexion S_int. La base de données BDD pourra contenir un répertoire utilisé pour définir une liste de participants à une réunion, comme cela est expliqué plus en détails ci-après.

[0032] La plateforme de visio-conférence P_vis est de préférence installée sur un serveur distinct du serveur d'authentification S_auth et du serveur d'interconnexion S_int.

[0033] Les participants P1 -Pn, 11 -Im souhaitant se connecter à une réunion comportent à cet effet un terminal de communication T_com. Le terminal de communication T_com du participant P1 -Pn, 11 -Im pourra prendre la forme d’un navigateur ou de tout autre programme adapté ("user agent" en anglais) exécuté par un ordinateur ou un téléphone mobile, notamment de type smartphone, comportant des moyens de communication audio et vidéo.

[0034] On décrit ci-après les différentes étapes mises en oeuvre par le procédé selon l'invention comportant une phase d'organisation et une phase de connexion.

[0035] Suivant la phase d'organisation, le serveur de génération de liens d'invitation S_gen génère, pour chaque participant P1 -Pn, 11 -Im à la réunion, un lien d'invitation complexe individuel LICI vers la réunion. Le lien d'invitation complexe individuel LICI prend la forme d’un jeton (ou "token" en anglais), de type JSON Web Token tel que défini par un rfc de l’IETF, notamment le rfc7519, dont une charge utile ("payload" en anglais) contient des informations relatives aux caractéristiques et le cas échéant aux paramètres de contexte de la réunion ainsi que des informations relatives à l'identité de chaque participant P1 -Pn, 11 -Im auquel est destiné ledit lien d'invitation complexe individuel LICI. Un jeton est généré de façon à garantir l’intégrité des données contenues dans son entête ("header" en anglais) et dans sa charge utile, le tout étant signé numériquement avec une fonction de hashage choisie pour assurer un haut niveau de sécurité de l’encodage et dont la clé secrète est conservée sur le serveur d'interconnexion S_int ou, le cas échéant, sur le serveur d'authentification S_auth distinct du serveur d'interconnexion S_int. La fonction de hashage est de type SHA ou ECDSA.

[0036] Le serveur de génération de liens d'invitation S_gen génère, à partir de ces liens d’invitation complexe individuels, un alias de chaque lien d’invitation complexe individuel ALICI lequel alias est le produit d’une fonction de hashage apte à générer une empreinte numérique à partir du lien d’invitation complexe individuel LICI, notamment sous forme d’une chaîne de caractères UTF-8. L'empreinte numérique est unique pour chaque lien d’invitation complexe individuel LICI, conformément aux caractéristiques de la fonction de hashage et n’offre aucune possibilité de reconstituer le lien complexe original sans disposer d'une clé privée conservée de manière sécurisée sur le serveur d'interconnexion S_int ou le cas échéant, le serveur d'authentification S_auth.

[0037] Le serveur de génération de liens d'invitation S_gen envoie, par mail, chaque alias de lien d'invitation complexe ALICI au participant P1 -Pn, 11 -Im correspondant sous forme d’un lien hypertexte court.

[0038] Le serveur de génération de liens d'invitation S_gen envoie en outre vers le serveur d'interconnexion S_int ou le cas échéant vers le serveur d'authentification S_auth, un mécanisme de correspondance entre les alias des liens d'invitation complexes ALICI et les liens d'invitation complexes individuels LICI. Le mécanisme de correspondance pourra prendre la forme d'une table ou le cas échéant d'éléments cryptographiques sécurisés permettant d’assurer cette correspondance. Alternativement ou en complément, le mécanisme de correspondance est sauvegardé dans un espace de stockage dédié.

[0039] On décrit ci-après les différentes étapes de la phase de connexion. Dans une étape E1 , le participant P1 -Pn, 11 -Im en possession du lien hypertexte court l’utilise pour se connecter à un domaine correspondant, qui est un domaine hébergeant le serveur d'authentification S_auth dans le cadre d'un flux de connexion a) ou le cas échéant le serveur d'interconnexion S_int qui utilise le serveur d'authentification S_auth comme partenaire de confiance ("Relying Party' en anglais) dans le cas d'un flux de connexion b).

[0040] Dans le flux de connexion a), le serveur d'authentification S_auth requiert, dans une étape E2, du participant P1 -Pn, 11 -Im qui se connecte une authentification forte selon un procédé défini par le standard du W3C WebAuthn ou tout autre procédé équivalent, un déroulement de ladite authentification (cf. étape E3) étant immédiat dans le cas d’une personne connue ou bien qui passera par une phase d’enrôlement dans le cas d’une personne invitée.

[0041] En effet, pour les participants P1 -Pn connus, il a été possible de réaliser un premier challenge d'enregistrement qui sera reproduit pour les authentifications fortes futures. A cet effet, le serveur d'authentification S_auth met en oeuvre une étape préalable d’enregistrement d'au moins un “facteur d'authentification" choisi notamment parmi: un paramètre biométrique (empreinte digitale, reconnaissance faciale ou autre), au moins une saisie d'un code d'identification, une détection du terminal possédé par le participant P1 -Pn, une utilisation de clés d'authentification par exemple de type Yubikey, ou autre.

[0042] Le serveur d'authentification S_auth met ensuite en oeuvre une étape de vérification ultérieure du facteur d'authentification suite à la demande d'authentification du participant P1 -Pn. Avantageusement, l'authentification du participant P1 -Pn est effectuée en utilisant le standard FIDO2/WebAuthn.

[0043] Alternativement, pour effectuer une authentification d’un participant 11 -Im de type "invité", le serveur d'authentification S_auth met en oeuvre une étape d'envoi d'un code, typiquement un code à usage unique d’au moins quatre caractères, vers une adresse email ou un numéro de téléphone mobile du participant. Le participant P1 -Pn, 11 -Im pourra ensuite reproduire le code dans une fenêtre dédiée, lequel pourra être vérifié par le serveur d'authentification S_auth.

[0044] Dans un exemple de mise en oeuvre, un participant souhaitant accéder à une réunion doit dans un premier temps entrer un mot de passe mdp, tel que cela est illustré par la figure 4. Ensuite, afin de vérifier l'identité du participant, un code est envoyé au participant qui doit le reproduire dans une fenêtre F_c, tel que cela est illustré par la figure 5.

[0045] Si l’authentification forte échoue (cf. étape E3bis), le processus d'interconnexion s’interrompt, le cas échéant dans des conditions qui permettent d'empêcher la multiplication des tentatives d’attaque de type "force brute".

[0046] Si l’authentification est réussie, le serveur d'authentification S_auth transmet au serveur d'interconnexion S_int l’alias de lien d'invitation complexe individuel ALICI reçu. L'alias de lien d'invitation complexe individuel ALICI reçu est alors converti en lien d’invitation complexe individuel LICI correspondant dans les étapes E4 et E5. Ce dernier lien permet au serveur d'interconnexion S_int d’introduire l’utilisateur qui a réussi le challenge d'authentification forte, déclenchant ainsi l’utilisation du jeton contenant et révélant, dans une étape E6, les caractéristiques de la réunion et le cas échéant les paramètres de contexte, pour initier la connexion du participant authentifié P1 -Pn, 11 -Im.

[0047] Dans une étape E7, on connecte le participant authentifié P1 -Pn, 11 -Im à la visio-conférence. Cette connexion est opérée au travers des protocoles internet standard, notamment de type UDP et/ou TURN, ou de tout autre protocole internet de connexion avec le navigateur du participant P1 -Pn, 11 -Im ainsi authentifié équivalent, s’effectuant conformément aux informations du lien d'invitation complexe individuel LICI, notamment l’identité de la personne correspondante, transmis au serveur d'interconnexion S_int à l’issue de l’étape d’authentification forte, laquelle est la condition absolument nécessaire de la lecture des informations du lien d'invitation complexe individuel LICI.

[0048] Le participant P1 -Pn, 11 -Im peut alors utiliser son terminal pour participer à la visio-conférence au travers d’une couche de transport réseau sécurisée (TLS) ou de tout autre protocole équivalent assurant la transmission vers et depuis la plateforme de visio-conférence P_vis opérant selon un standard, tel qu'un standard de type WebRTC ou tout autre procédé équivalent.

[0049] Le participant P1 -Pn, 11 -Im a ainsi accès à la réunion avec un nom donné, lequel est, de manière inaltérable et infalsifiable, le nom particulier du participant P1 -Pn, 11 -Im, associé par l'organisateur à l'invitation particulière et donc au lien d'invitation complexe individuel LICI correspondant.

[0050] Dans le flux de connexion b), le procédé est identique sauf que le serveur d'interconnexion S_int sollicite le serveur d'authentification S_auth à l'égard de qui il est partenaire de confiance, lequel serveur d'authentification S_auth requiert du participant P1 -Pn, 11 -Im qui se connecte une authentification forte selon un procédé utilisant le standard WebAuthn du W3C ou tout autre procédé équivalent, un déroulement de ladite authentification étant immédiat dans le cas d’un lien de convocation et dont le déroulement sera immédiat dans le cas d’une personne connue ou bien qui passera par une phase d’enrôlement dans le cas d’une personne invitée.

[0051 ] Lorsque l’authentification est réussie, le serveur d'authentification S_auth transmet au serveur d'interconnexion S_int une information que l'authentification forte a bien été accomplie et que l'alias de lien d'invitation complexe individuel ALICI peut être traité, ledit alias de lien d'invitation complexe individuel ALICI étant alors converti en lien d’invitation complexe individuel LICI correspondant. Ce dernier lien permet au serveur d'interconnexion S_int d’introduire l’utilisateur qui a réussi le challenge d'authentification forte, déclenchant ainsi l’utilisation du jeton, contenant et révélant les caractéristiques de la réunion et le cas échéant les paramètres de contexte, pour initier la connexion du participant authentifié P1 -Pn, 11 -Im.

[0052] La figure 2b illustre le cas où le serveur S_gen de génération de liens d'invitation associé à la base de données BDD ainsi que le serveur d'interconnexion S_int sont hébergés chez un organisateur, tandis que le serveur d'authentification S_auth est hébergé chez un partenaire de confiance.

[0053] Dans une étape E1 ', le terminal T_com du participant P1 se connecte au serveur S_gen de génération de liens invitation via un alias de lien d'invitation complexe individuel ALICI. Dans une étape E1 bis', Le serveur S_gen de génération de liens d'invitation transmet l'alias ALICI au serveur d'authentification S_auth Le serveur d'authentification S_auth effectue une demande d'authentification au participant P1 -Pn dans une étape E2'. Le participant P1 -Pn répond au challenge d'identification dans une étape E3'. [0054] Dans une étape E4', le serveur d'authentification S_auth envoie une information relative à la réussite ou à l'échec du challenge d'authentification. En cas d'échec, le processus est interrompu. Dans le cas où l'authentification a réussi, l'alias de lien d'invitation complexe individuel ALICI est converti en lien d’invitation complexe individuel LICI correspondant. Ce lien permet au serveur d'interconnexion S_int d’introduire l’utilisateur qui a réussi le challenge d'authentification forte, déclenchant déclenchant ainsi l’utilisation du jeton pour initier la connexion du participant authentifié P1 -Pn, 11 -Im.

[0055] En outre, étant donné que le procédé définit des paramètres de réunion, une liste de participants P1 -Pn, 11 -Im ainsi qu'une politique de sécurité, il sera possible de vérifier que la réunion ne voit pas se connecter plusieurs personnes ayant le même nom sous des adresses différentes, ou des invités dont la connexion n'a pas été sécurisée ou toute autre anomalie ou incohérence. La définition du périmètre de la réunion par l'ensemble de ces paramètres réunit les conditions nécessaires et suffisantes pour que des programmes de contrôle puissent vérifier le bon déroulement de la réunion tel que l'organisateur l'avait prévu.

[0056] Bien entendu, les différentes caractéristiques, variantes et/ou formes de réalisation de la présente invention peuvent être associées les unes avec les autres selon diverses combinaisons dans la mesure où elles ne sont pas incompatibles ou exclusives les unes des autres.

[0057] En outre, l'invention n'est pas limitée aux modes de réalisation décrits précédemment et fournis uniquement à titre d'exemple. Elle englobe diverses modifications, formes alternatives et autres variantes que pourra envisager l'homme du métier dans le cadre de la présente invention et notamment toutes combinaisons des différents modes de fonctionnement décrits précédemment, pouvant être pris séparément ou en association.