WO2023083771A1

WO2023083771A1 - Procédés de contrôle, de vérification et de configuration, et entités configurées pour mettre en œuvre ces procédés

Info

Publication number: WO2023083771A1
Application number: PCT/EP2022/081047
Authority: WO
Inventors: Mohamed Boucadair; Christian Jacquenet
Original assignee: Orange SA
Current assignee: Orange SA
Priority date: 2021-11-10
Filing date: 2022-11-08
Publication date: 2023-05-19
Anticipated expiration: 2024-05-10
Also published as: US20250007795A1; FR3129048A1; EP4430812A1

Abstract

Le procédé de contrôle d'une vérification opérée sur des données véhiculées dans un réseau lors d'un accès par un premier dispositif d'un utilisateur à un service fourni par un deuxième dispositif via une connexion principale, est mis en œuvre par une entité de contrôle et comprend: - le déclenchement auprès d'une entité de coordination d'une configuration du service pour que des données véhiculées sur ladite connexion principale et sur au moins une connexion secondaire établie en marge de ladite connexion principale pour fournir le service transitent par une entité de vérification sélectionnée par ladite entité de contrôle pour analyser lesdites données; - la notification de ladite entité de coordination si un événement est détecté dans une identité numérique dudit utilisateur véhiculée lors de l'accès audit service et comprenant des informations d'identification de l'utilisateur obtenues à partir desdites données analysées par ladite entité de vérification.

Description

Procédés de contrôle, de vérification et de configuration, et entités configurées pour mettre en œuvre ces procédés

L’invention appartient au domaine général des télécommunications.

Elle concerne plus particulièrement la gestion de données sensibles véhiculées sur un réseau de communication (ex. réseau IP (pour « Internet Protocol » en anglais)) lors d’un accès par un premier dispositif, tel qu’un équipement client (ex. un terminal d’un utilisateur ou un CPE (pour « Customer Premises Equipment » en anglais)), à un service fourni par un deuxième dispositif, tel qu’un serveur ou une plateforme de service.

Les données sensibles auxquelles s’intéresse l’invention sont plus spécifiquement des informations qui contribuent à l’identification d’un individu, désignées ici par « informations d’identification », telles que définies notamment en section 5.2.2 du document RFC 6973 édité par l’IETF et intitulé « Privacy Considerations for Internet Protocols », juillet 2013. De telles informations d’identification peuvent être liées à un individu particulier et être utilisées, seules ou en combinaison avec d’autres éléments, pour déduire ou reconnaître l’identité de cet individu. Elles peuvent être de natures diverses et variées ; il peut s’agir notamment d’identifiants à proprement parler de l’utilisateur ou de l’équipement utilisé par ce dernier, mais également d’autres données comme sa localisation ou la localisation de voisins d’un équipement (ex. terminal) de cet utilisateur, de logs de l’utilisateur sur un ou plusieurs sites web, de champs particuliers de messages caractéristiques de protocoles de communication, etc. De nombreuses informations sont en effet susceptibles d’apporter des indications sur l’identité de l’utilisateur, seules ou en combinaison avec d’autres informations.

Comme le souligne le document RFC 6973, dans certains contextes, il est parfaitement légitime d’identifier des individus (auteurs d’attaques par déni de service ou DDoS (pour « Distributed Denial of Service » en anglais), par exemple). Toutefois, dans d’autres contextes, une telle identification peut être problématique, par exemple parce qu’elle empêche l’individu de bénéficier d’un anonymat nécessaire à son activité ou à une opération à laquelle il participe, ou parce qu’elle divulgue des éléments pouvant porter atteinte à la vie privée de l’individu ou à celle d’autres individus, ou encore parce qu’elle donne la possibilité d’exercer un contrôle sur l’individu en question ou un traitement différencié, etc.

Aujourd’hui, l’utilisation massive des moyens de communication, la prolifération des applications logicielles installées sur les terminaux des utilisateurs (ex. téléphones intelligents ou « smartphones » en anglais, ordinateurs portables, tablettes) et la sophistication des briques technologiques sous-jacentes, conduisent à une collecte toujours plus importante de données qui peuvent être partagées avec diverses plateformes, telles que des plateformes de service ou d’autres infrastructures sollicitées lors de l’accès à des services (ex. plateforme de publicité ou de traçage web (aussi connu sous le nom de « web tracking » en anglais)), et ce généralement à l’insu des utilisateurs. On désigne dans la suite de façon générale par « données de télémétrie », ces données ainsi collectées et partagées.

La collecte de données de télémétrie ne se restreint pas aux données utiles pour le bon fonctionnement d’une application ou d’un service mais peut comprendre également des informations d’identification divulguant des éléments sensibles relevant de la vie privée des utilisateurs. De même, elle ne se limite pas à certaines applications mais concerne également la plupart des systèmes d’exploitation (ou OS pour « Operating System », en anglais) installés sur les terminaux des utilisateurs. Par exemple, les systèmes d’exploitation installés sur les terminaux mobiles envoient les données de télémétrie suivantes vers des infrastructures gérées par les fournisseurs des systèmes d’exploitation en question : identifiant IMEI (pour « International Mobile Equipment Identity » en anglais), numéro de série, numéro de série de la carte SIM (pour « Subscriber Identity Module » en anglais), numéro de téléphone public, adresse IP locale, adresse MAC (pour « Medium Access Control » en anglais) du terminal, adresses MAC des terminaux disponibles à proximité, ainsi que d’autres identifiants uniques. Ces pratiques ne sont toutefois pas spécifiques aux terminaux mobiles.

Les données de télémétrie remontées par le ou les systèmes d’exploitation d’un terminal, corrélées avec des données d’accès à certains services, peuvent permettre de reconnaître l’identité de l’utilisateur du terminal, voire divulguer des informations qui portent atteinte à sa vie privée ou à celle d’autres individus qui n’utilisent même pas lesdits services.

Par exemple, la collecte des adresses MAC des terminaux à proximité du terminal d’un utilisateur permet de construire dans le temps une sorte de réseau qui donne des indications sur les relations sociales, les centres d’intérêt, ainsi que d’autres informations sensibles et caractéristiques de l’utilisateur.

En effet, les données de télémétrie remontées par un terminal donné peuvent être utilisées pour tracer d’autres terminaux même s’ils ne supportent pas un système d’exploitation donné. A titre illustratif, supposons un terminal H, connecté à un réseau local, et ayant un système d’exploitation OS#1 configuré pour informer par exemple une infrastructure OSCloud située dans le cloud de la présence d’un terminal vH voisin du terminal H, supportant un autre système d’exploitation OS#2. Le terminal H peut ainsi révéler l’adresse MAC (mac@1) de vH, transmettre des données relatives à sa localisation, etc. Lorsque le terminal vH se connecte à un autre réseau, les terminaux connectés à cet autre réseau et équipés du même système d’exploitation OS#1, informent à leur tour l’infrastructure OSCloud de la présence du terminal vH et son adresse MAC (@mac1), transmettent des données relatives à sa localisation, etc. L’identification du terminal vH peut alors se faire aisément par l’infrastructure OSCloud en corrélant l’ensemble des informations reçues : adresses MAC et/ou toute(s) autre(s) donnée(s) de télémétrie rapportée(s) par les terminaux équipés du système d’exploitation OS#1.

A priori, la grande majorité des utilisateurs ne disposent pas de moyens pour détecter (et empêcher) l’envoi de telles données de télémétrie et éviter leur partage avec des entités externes. Il convient de noter que l’activation du mode « privé » offert par certaines applications (comme par exemple, certains navigateurs Web) n’empêche pas l’envoi de données de télémétrie par ces applications.

On peut envisager de mettre en place des mécanismes de certification et d’audit pour vérifier les données de télémétrie collectées par une infrastructure de service et s’assurer que les données de télémétrie ainsi collectées sont nécessaires pour la fourniture de ce service. Ces mécanismes peuvent être mis en œuvre notamment par des serveurs dit autoritaires (ou « authoritative servers », en anglais) avec lesquels les terminaux des utilisateurs du service établissent des connexions pour accéder au service, récupérer un contenu, etc. De tels mécanismes ont pour objectifs d’une part, de s’assurer que les données de télémétrie collectées sont compatibles avec les conditions générales d’utilisation (ou CGU) du service et d’autre part, de vérifier qu’elles n’enfreignent pas les dispositions législatives/réglementaires en vigueur (par exemple en Union Européenne, le règlement général sur la protection des données ou RGPD). Ces mécanismes peuvent être mis en place à la demande du fournisseur du service, d’une autorité de régulation locale, ou tout autre organisme.

Toutefois, auditer localement le ou les serveurs autoritaires d’une infrastructure de service n’est pas suffisant pour tirer des conclusions quant au respect des dispositions couvertes par l’audit. En effet, un service peut impliquer une infrastructure complexe, aussi appelée domaine de service (ou « Service Realm » en anglais), qui ne se résume pas aux serveurs autoritaires. Cette infrastructure complexe peut impliquer notamment des serveurs frontaux, des répartiteurs de charge (ou « load balancers » en anglais), des serveurs terminant les connexions sécurisées (ex. connexions TLS (pour « Transport Layer Security » en anglais)), des serveurs de rétention de données (ou « logging » en anglais), des serveurs de distribution de contenus, etc. De plus, la livraison du service peut être distribuée et impliquer, par exemple, un cluster anycast, des serveurs cache, etc. Certains fournisseurs de service offrent aussi un service DNS (pour « Domain Name System » en anglais), un service de traçage, etc.

Plusieurs serveurs peuvent donc être sollicités pour la fourniture d’un même service, y compris lorsque ce service est un « simple » accès à un site web. Une connexion établie vers un serveur autoritaire au titre d’un service, désignée ici par « connexion principale », est donc le plus souvent complétée d’un ensemble de sous-connexions vers d’autres serveurs, désignées ici par « connexions secondaires » : autrement dit, l’accès à un service est le résultat de la combinatoire d’une pluralité de connexions incluant la connexion principale et une ou plusieurs connexions secondaires. Chacune de ces connexions secondaires peut elle-même donner lieu à l’établissement d’autres connexions. Les informations collectées par tous les serveurs avec lesquels ces différentes connexions ont été établies peuvent être corrélées et utilisées à des fins de profilage, d’identification, ou de suivi des utilisateurs, etc. Auditer le ou les services autoritaires d’un service est donc insuffisant pour apprécier le respect des clauses de confidentialité d’un service.

L’invention propose une solution permettant d’opérer une vérification des données de télémétrie véhiculées sur un réseau tout en tenant compte de la complexité des infrastructures de service.

Plus particulièrement, l’invention concerne selon un premier aspect, un procédé de contrôle d’une vérification opérée sur des données véhiculées dans au moins un réseau de communication lors d’un accès par un premier dispositif d’un utilisateur à un service fourni par un deuxième dispositif via une connexion dite principale établie entre le premier et le deuxième dispositif, ce procédé étant destiné à être mis en œuvre par une entité de contrôle et comprenant :

une étape de déclenchement, auprès d’une entité de coordination, d’une configuration du service pour que des données véhiculées sur la connexion principale et sur au moins une connexion secondaire établie en marge (c’est-à-dire en complément) de cette connexion principale pour la fourniture du service transitent par au moins une entité de vérification sélectionnée par l’entité de contrôle pour analyser ces données ; et
une étape de notification de l’entité de coordination, si un événement déterminé est détecté dans une identité numérique de l’utilisateur véhiculée lors de l’accès au service et comprenant des informations d’identification de l’utilisateur obtenues à partir des données analysées par ladite au moins une entité de vérification.

Corrélativement, l’invention vise également une entité de contrôle d’une vérification opérée sur des données véhiculées dans au moins un réseau de communication lors d’un accès par un premier dispositif d’un utilisateur à un service fourni par un deuxième dispositif via une connexion dite principale établie entre le premier et le deuxième dispositif, cette entité de contrôle comprenant :

un module de déclenchement, configuré pour déclencher auprès d’une entité de coordination, une configuration du service pour que des données véhiculées sur la connexion principale et sur au moins une connexion secondaire établie en marge de cette connexion principale pour la fourniture du service transitent par au moins une entité de vérification sélectionnée par l’entité de contrôle pour analyser ces données ; et
un module de notification, configuré pour notifier l’entité de coordination, si un événement déterminé est détecté dans une identité numérique de l’utilisateur véhiculée lors de l’accès au service et comprenant des informations d’identification de l’utilisateur obtenues à partir des données analysées par ladite au moins une entité de vérification.

L’entité de coordination est par exemple hébergée par l’infrastructure offrant le service. Elle contrôle les éléments impliqués lors de la fourniture du service, et est ainsi en mesure de configurer le service, sur commande de l’entité de contrôle, pour que tout ou partie des données véhiculées sur les connexions principale et secondaires transitent via une ou plusieurs entités de vérification sélectionnées par l’entité de contrôle pour analyser ces données et déterminer notamment si elles contiennent des informations d’identification de l’utilisateur. De telles informations d’identification, lorsqu’elles sont détectées par la ou les entités de vérification diligentées par l’entité de contrôle, sont consignées par cette ou ces dernières dans une identité numérique de l’utilisateur associée au service (qui reflète l’identité numérique de l’utilisateur maintenue par le service). Il convient de noter, comme souligné précédemment en référence au document RFC 6973, que la notion d’informations d’identification au sens de l’invention n’inclut pas seulement des informations qui à elles seules identifient sans ambiguïté l’utilisateur. Cette notion comprend également d’autres informations qui induisent (par exemple du fait de leur ordre d’apparition dans les messages émis par l’équipement client de l’utilisateur) des précisions sur l’identité de l’utilisateur ou qui, corrélées entre elles ou avec d’autres éléments, permettent d’obtenir de telles précisions. De telles informations d’identification consistent par exemple en l’identification d’un réseau d’accès auquel est connecté l’équipement client de l’utilisateur, la localisation de l’équipement client de l’utilisateur, une adresse MAC d’un équipement client voisin, etc. L’identité numérique alimentée par la ou les entités de vérification peut comprendre non seulement les informations d’identification extraites directement des données analysées par cette ou ces dernières, mais également les précisions apportées par ces informations d’identification ou obtenues par corrélation de ces informations d’identification (éventuellement avec d’autres éléments), qui constituent en tant que telles également des informations d’identification au sens de l’invention.

En fonction du contenu de l’identité numérique collectée par les entités de vérification, l’entité de contrôle peut être amenée à notifier l’entité de coordination. Par exemple, une telle notification peut être déclenchée sur détection d’au moins un événement par une dite entité de vérification parmi :

une nouvelle plateforme de collecte de données impliquée dans l’accès audit service ;
un niveau d’exposition d’informations d’identification de l’utilisateur supérieur à un seuil donné ;
une nouvelle information d’identification de l’utilisateur détectée par ladite au moins une entité de vérification dans lesdites données analysées ;
une information d’identification de l’utilisateur transmise à une entité tierce qui ne respecte pas des conditions d’utilisation dudit service approuvées par ledit utilisateur.

L’invention propose donc une solution collaborative s’appuyant sur une entité de contrôle commandant une ou plusieurs entités de vérification situées sur des chemins empruntés par les données de la connexion principale et par celles des connexions secondaires établies en marge de cette connexion principale, et sur une entité de coordination, apte à configurer le service pour que les données véhiculées lors de l’accès au service transitent par les entités de vérification en question pour être analysées. L’identité numérique alimentée par les entités de vérification à partir des données qu’elles analysent des informations d’identification de l’utilisateur, permet de corréler les résultats des analyses menées le cas échéant par chacune des entités de vérification et de détecter d’éventuelles failles concernant ces informations d’identification lors de la fourniture du service, susceptibles d’être préjudiciables à l’utilisateur (ex. révélation d’informations sensibles). L’entité de coordination en est alors informée, et peut prendre rapidement des mesures pour remédier à ces failles et/ou en informer l’utilisateur (en adaptant par exemple ses conditions générales d’utilisation).

Par exemple, la corrélation permise par l’invention via la constitution de l’identité numérique de l’utilisateur peut révéler des pratiques telles que la délégation de sous-domaines à des tiers moyennant une redirection du trafic (technique dite de « CNAME (Canonical NAME) cloaking », en anglais). Cette pratique permet à des tiers de déposer sur le dispositif de l’utilisateur des « cookies » qui sont considérés comme des cookies « first party » (c’est-à-dire permettant de sauvegarder par exemple des préférences ou un identifiant (« login » en anglais) de l’utilisateur lors de l’accès à un site), ce qui permet d’éviter d’éventuels blocages mis en place par les navigateurs. Une telle pratique ouvre la porte à une faille sécuritaire importante, car, de facto, elle permet à des tiers d’accéder à des jetons d’authentification stockés dans les cookies.

L’invention offre donc la possibilité de réaliser dynamiquement (c’est-à-dire à la demande) un audit (i.e. une vérification) global du service permettant d’identifier les informations sensibles relatives à un utilisateur et partagées entre les différentes infrastructures impliquées dans ou sollicitées lors de l’invocation du service et de caractériser le traitement qui est fait de ces informations sensibles. L’audit global proposé par l’invention est donc un audit dont les résultats permettront à un utilisateur du service de mieux protéger sa vie privée (que l’on peut aussi désigner par souci de simplification par « audit de protection de la vie privée »). L’invention ne se limite pas à auditer le serveur autoritaire impliqué dans la fourniture du service (« audit sur site »), mais permet également de diligenter des audits hors site permettant de disposer d’une vue globale des informations d’identification de l’utilisateur véhiculées et partagées lors de l’invocation du service. L’invention permet en particulier de détecter une exposition indue de ces informations sensibles, telle qu’une exposition non conforme à des conditions générales d’utilisation acceptées par l’utilisateur et/ou à des dispositions réglementaires.

L’invention peut être avantageusement couplée à un mécanisme d’audit sur site, qui permet pour sa part d’évaluer certaines pratiques comme le stockage des données, des « scripts » tels que des algorithmes d’extraction de données activés sur le serveur autoritaire etc., de sorte à fiabiliser davantage les conclusions de l’audit conduit grâce à l’invention.

Dans un mode particulier de réalisation, l’étape de déclenchement est conditionnée par une acceptation préalable de l’entité de coordination de procéder à l’analyse desdites données.

Cette acceptation préalable peut prendre différentes formes, comme par exemple la vérification que l’entité de contrôle est autorisée à déclencher une telle analyse conformément à un accord d’audit statique conclu préalablement entre le fournisseur du service et le fournisseur du service d’audit (c’est-à-dire l’entité qui gère l’entité de contrôle et les entités de vérification), ou un échange dynamique mis en place entre l’entité de coordination et l’entité de contrôle en utilisant le protocole CPNP (pour « Connectivity Provisioning Negotiation Protocol ») défini dans le document RFC 8921 édité par l’IETF en octobre 2020, etc. Cet accord ou cet échange dynamique préalable permet de délimiter le périmètre de l’audit de protection de la vie privée réalisé par l’entité de contrôle et les entités de vérification, et notamment les flux de données à analyser (ex. tous les flux, quelle que soit leur origine ou une ou plusieurs catégories spécifiques de flux), le ou les utilisateurs concernés, les connexions à auditer (sélection aléatoire ou ciblée, résultant d’une demande explicite d’un administrateur ou exécutée en fonction d’événements externes, comme par exemple le changement de règles générales d’utilisation), etc.

Dans un mode particulier de réalisation, le procédé de contrôle comprend une étape de sélection de ladite au moins une entité de vérification en fonction d’au moins une contrainte du service prédéterminée ou transmise par l’entité de coordination.

Une telle contrainte est par exemple un délai de détour maximum autorisé, une zone géographique, un numéro de système autonome (ou AS pour « Autonomous System »), etc. Ceci permet avantageusement de s’assurer que le processus d’audit ou de vérification est transparent pour l’utilisateur ou tout du moins de minimiser son impact sur la qualité d’expérience telle que perçue par l’utilisateur.

Dans un mode particulier de réalisation, l’étape de déclenchement du procédé de contrôle comprend une fourniture à ladite entité de coordination d’une information de joignabilité de ladite au moins une entité de vérification.

Une telle information de joignabilité est par exemple une adresse IP ou un nom de domaine correspondant à ladite au moins une entité de vérification. Elle permet à l’entité de coordination de programmer la chaîne de service pour inclure la ou les entités de vérification dans le chemin des données qui sont destinées à être analysées par cette ou ces entités de vérification. A cet effet, différentes solutions peuvent être envisagées : modification de la chaîne de résolution de noms de domaine (DNS) pour que l’information de joignabilité de la ou des entités de vérification soit communiquée au premier dispositif, activation d’un mécanisme de chaînage de service (ou SFC pour « Service Function Chaining » en anglais) pour que la ou les entités de vérification soient invoquées dans les chemins empruntés par les données destinées à être analysées par ces dernières, redirection des données destinées à être analysées vers la ou les entités de vérification, etc.

Comme il apparaît au vu de ce qui précède, l’invention s’appuie sur l’entité de contrôle, mais également sur la ou les entités de vérification sélectionnées par l’entité de contrôle pour le traitement des données.

Ainsi, selon un deuxième aspect, l’invention vise également un procédé de traitement, par une entité de vérification, de données véhiculées sur au moins un réseau de communication lors d’un accès par un premier dispositif d’un utilisateur à un service fourni par un deuxième dispositif via une connexion dite principale établie entre le premier et le deuxième dispositif, au moins une connexion dite secondaire étant établie en marge de ladite connexion principale lors de la fourniture dudit service, ledit procédé comprenant :

une étape de réception de données véhiculées via ladite connexion principale et/ou au moins une dite connexion secondaire ;
si au moins une information d’identification de l’utilisateur est obtenue à partir desdites données reçues, en fonction de ladite au moins une information d’identification obtenue, une étape de mise à jour d’une identité numérique de l’utilisateur véhiculée lors de l’accès audit service ; et
une étape de relai desdites données reçues vers un destinataire desdites données.

Corrélativement, l’invention concerne aussi une entité de vérification de données véhiculées sur au moins un réseau de communication lors d’un accès par un premier dispositif d’un utilisateur à un service fourni par un deuxième dispositif via une connexion dite principale établie entre le premier et le deuxième dispositif, au moins une connexion dite secondaire étant établie en marge de ladite connexion principale lors de la fourniture dudit service, ladite entité de vérification comprenant :

un module de réception, configuré pour recevoir des données véhiculées via ladite connexion principale et/ou au moins une dite connexion secondaire ;
un module de mise à jour, activé si au moins une information d’identification de l’utilisateur est obtenue à partir desdites données, et configuré pour mettre à jour une identité numérique de l’utilisateur véhiculée lors de l’accès audit service en fonction de ladite au moins une information d’identification obtenue ; et
un module de transmission configuré pour relayer lesdites données reçues vers un destinataire desdites données.

Ainsi, préférentiellement, la mise à jour de l’identité numérique n’est réalisée que si la ou les informations d’identification détectées le cas échéant dans les données ne sont pas déjà contenues dans l’identité numérique collectée par les entités de vérification et associée audit service.

L’entité de vérification et le procédé de traitement selon l’invention bénéficient des mêmes avantages cités précédemment que l’entité de contrôle et le procédé de contrôle selon l’invention.

Dans un mode particulier de réalisation, le procédé de traitement comprend en outre une étape d’analyse des données reçues pour déterminer si elles véhiculent (de manière explicite ou implicite (dans ce cas ; l’analyse des données observées permet de déduire des informations d’identification supplémentaires) au moins une information d’identification de l’utilisateur, ladite étape d’analyse utilisant au moins un paramètre avec lequel ladite entité de vérification a été préalablement configurée et/ou qu’elle a acquis via une exécution d’un algorithme d’apprentissage machine (ou « machine learning » en anglais).

Ainsi, différentes options sont possibles pour détecter des informations sensibles (qui peuvent être mises en œuvre de façon alternative ou complémentaire) véhiculées par les données transmises sur les connexions principale et secondaires. Selon une première option, l’entité de vérification peut être configurée préalablement avec un ensemble de paramètres déterminés lui permettant de reconnaître des informations d’identification parmi les données analysées. De tels paramètres peuvent être par exemple des entêtes particuliers de messages à rechercher tels que ceux utilisés par un système d’exploitation, ou des informations d’identification spécifiques (déterminées à l’avance, comme un identifiant MSISDN (pour « Mobile Station ISDN Number » en anglais) ou IMEI (pour « International Mobile Equipment Identity » en anglais), un numéro de série, etc.), ou une séquence ordonnée de certaines données dans un paquet de données. Selon une deuxième option, l’entité de vérification peut acquérir dynamiquement de tels paramètres, via un algorithme d’apprentissage machine qui, par exemple, est en mesure de détecter des identifiants persistants impliqués dans un échange lié au service. Cet algorithme d’apprentissage machine peut être paramétré par le fournisseur du service d’audit, par exemple dans le respect des informations contractuelles qui définissent sa relation avec ses clients (par exemple une autorité de régulation peut être à l’origine de l’audit pour vérifier le respect des engagements pris par le fournisseur de service auprès de ses clients) ou par un autre acteur, comme par exemple l’utilisateur. Il convient de noter que les résultats de l’algorithme peuvent différer selon la nature du paramétrage et l’entité qui effectue ce paramétrage. Si un acteur autre que le fournisseur du service d’audit est envisagé, alors préférentiellement une procédure est mise en œuvre pour sécuriser ce paramétrage et s’assurer qu’il est bien autorisé (par exemple partage d’un identifiant unique entre l’acteur et l’entité de contrôle, qui communique cet identifiant à l’entité de coordination pour pouvoir identifier ultérieurement l’acteur).

Dans un mode de réalisation particulier, le procédé de traitement comprend en outre :

une étape d’obtention d’une liste d’informations d’identification déclarées comme étant véhiculées lors de l’accès audit service et/ou un ou des traitements appliqués à ladite liste d’informations d’identification ;
une étape de vérification de la conformité de l’identité numérique de l’utilisateur à ladite liste et/ou auxdits traitements obtenus ; et
une étape de signalement en cas de non-conformité.

En d’autres termes, l’entité de vérification est chargée d’analyser l’identité numérique de l’utilisateur collectée conformément à l’invention lors de l’accès au service par l’utilisateur, et de déterminer si elle est conforme à ce qui est attendu (c’est-à-dire telle que déclarée par le fournisseur du service ou par les fournisseurs des services annexes invoqués sur les connexions secondaires lors de l’accès au service). Dans le cas contraire, l’entité de vérification le signale à différentes entités selon plusieurs variantes : ce signalement peut se faire en envoyant par exemple une notification à l’entité de contrôle, qui se charge de la relayer vers l’entité de coordination par exemple ou vers l’utilisateur, ou encore vers le fournisseur du service d’audit ou vers l’ensemble de ces entités. En variante, l’entité de vérification peut ajouter un indicateur dans l’identité numérique auquel l’entité de contrôle ou l’utilisateur peut accéder.

Dans un autre mode de réalisation, on peut envisager que cette analyse soit confiée à une autre entité qu’à une entité de vérification. Cela peut être pertinent notamment lorsque plusieurs entités de vérification sont chargées par l’entité de contrôle d’analyser les données véhiculées lors de l’accès au service par l’utilisateur. Dès lors, on doit s’assurer que cette autre entité ait accès à l’identité numérique collectée par la ou les entités de vérification. Il peut s’agir de l’entité de contrôle (qui gère la pluralité d’entités de vérification et a accès à l’identité numérique) ou à une entité tierce.

Dans un mode particulier de réalisation, le procédé de traitement comprend une étape de signalement à une entité de contrôle d’au moins un événement détecté par l’entité de vérification parmi :

Cette liste n’est bien entendu pas exhaustive. Ainsi, d’autres analyses peuvent être conduites par l’entité de vérification ou l’autre entité (entité de contrôle ou entité tierce) à partir de l’identité numérique de l’utilisateur collectée lors de l’accès au service.

Dans un mode particulier de réalisation, le procédé de traitement comprend une étape d’envoi au premier dispositif d’un entête comprenant une information de joignabilité de ladite au moins une entité de vérification, ledit entête indiquant audit premier dispositif qu’il doit envoyer ses requêtes de résolution de noms de domaine vers ladite au moins une entité de vérification.

Autrement dit, ce mode de réalisation propose une configuration DNS dynamique du premier dispositif, adaptée à la mise en œuvre de l’invention. Elle permet en effet avantageusement de s’assurer que l’entité de vérification trace toutes les connexions secondaires établies en marge de la connexion principale dans le cadre de l’accès au service par l’utilisateur.

Comme évoqué précédemment, l’invention concerne également selon un troisième aspect, une entité de coordination et le procédé mis en œuvre par cette entité de coordination.

Plus particulièrement, l’invention vise un procédé de configuration d’un service fourni à un premier dispositif par un deuxième dispositif via une connexion dite principale établie entre le premier et le deuxième dispositif, ledit procédé de configuration étant destiné à être mis en œuvre par une entité de coordination et comprenant, sur requête d’une entité de contrôle, une étape de configuration du service pour que des données véhiculées sur ladite connexion principale et sur au moins une connexion secondaire établie en marge de ladite connexion principale pour la fourniture du service transitent par au moins une entité de vérification sélectionnée par ladite entité de contrôle pour analyser lesdites données.

Corrélativement, l’invention concerne aussi une entité de coordination apte à configurer un service fourni à un premier dispositif par un deuxième dispositif via une connexion dite principale établie entre le premier et le deuxième dispositif, ladite entité de coordination comprenant un module de configuration, activé sur requête d’une entité de contrôle et programmé pour configurer ledit service pour que des données véhiculées sur ladite connexion principale et sur au moins une connexion secondaire établie en marge de ladite connexion principale pour la fourniture du service transitent par au moins une entité de vérification sélectionnée par ladite entité de contrôle pour analyser lesdites données.

L’entité de coordination et le procédé de configuration selon l’invention bénéficient des mêmes avantages cités précédemment que l’entité de contrôle, l’entité de vérification, le procédé de contrôle et le procédé de traitement selon l’invention.

Dans un mode particulier de réalisation, l’étape de configuration est précédée d’une étape de vérification qui consiste à vérifier si ladite entité de contrôle est autorisée à déclencher une analyse desdites données par ladite au moins une entité de vérification.

Ceci permet de s’assurer d’une collaboration entre l’entité de contrôle et l’entité de coordination du service.

Comme évoqué précédemment, dans un mode particulier de réalisation, le procédé de configuration comprend une étape de transmission à ladite entité de contrôle d’au moins une contrainte dudit service à tenir compte pour sélectionner ladite au moins une entité de vérification.

Dans un autre mode de réalisation, l’étape de configuration comprend un déclenchement :

d'une modification d’un mécanisme de résolution de noms de domaine pour inclure une information de joignabilité de ladite au moins une entité de vérification ; ou
d’une activation d’un mécanisme de chaînage de service impliquant ladite au moins une entité de vérification ; ou
d’un mécanisme de routage à la source ; ou
d’une redirection des données vers ladite au moins une entité de vérification.

Ceci permet de s’assurer que les données de la connexion principale et des connexions secondaires transitent via la ou les entités de vérification désignées pour analyser les données.

Dans un mode particulier de réalisation, le déclenchement d’une modification d’un mécanisme de résolution de noms de domaine comprend l’envoi au premier dispositif d’un entête comprenant ladite information de joignabilité de ladite au moins une entité de vérification, ledit entête indiquant audit premier dispositif qu’il doit envoyer ses requêtes de résolution de noms de domaine vers ladite au moins une entité de vérification.

Dans un mode particulier de réalisation du procédé de configuration selon l’invention, le déclenchement d’une modification d’un mécanisme de résolution de noms de domaine comprend une activation au niveau d’une entité impliquée dans la fourniture du service d’un envoi au premier dispositif d’un entête comprenant ladite information de joignabilité de ladite au moins une entité de vérification, ledit entête indiquant audit premier dispositif qu’il doit envoyer tout ou partie de ses requêtes de résolution de noms de domaine vers ladite au moins une entité de vérification.

Dans un mode particulier de réalisation, les procédés de contrôle, de traitement et/ou de configuration sont mis en œuvre par un ordinateur.

L’invention vise également un programme d’ordinateur sur un support d’enregistrement, ce programme étant susceptible d’être mis en œuvre dans un ordinateur ou plus généralement dans une entité de contrôle conforme à l’invention et comporte des instructions adaptées à la mise en œuvre d’un procédé de contrôle tel que décrit ci-dessus.

L’invention vise également un programme d’ordinateur sur un support d’enregistrement, ce programme étant susceptible d’être mis en œuvre dans un ordinateur ou plus généralement dans une entité de vérification conforme à l’invention et comporte des instructions adaptées à la mise en œuvre d’un procédé de traitement tel que décrit ci-dessus.

L’invention vise aussi un programme d’ordinateur sur un support d’enregistrement, ce programme étant susceptible d’être mis en œuvre dans un ordinateur ou plus généralement dans une entité de coordination conforme à l’invention et comporte des instructions adaptées à la mise en œuvre d’un procédé de configuration tel que décrit ci-dessus.

Chacun de ces programmes 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'information ou un support d’enregistrement lisibles par un ordinateur, et comportant des instructions d’un programme d'ordinateur tel que mentionné ci-dessus.

Le support d'information ou d’enregistrement peut être n'importe quelle entité ou dispositif capable de stocker les programmes. 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, ou une mémoire flash.

D'autre part, le support d'information ou d’enregistrement peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par lien radio, par lien optique sans fil ou par d'autres moyens.

Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.

Alternativement, le support d'information ou d’enregistrement peut être un circuit intégré dans lequel un programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution des procédés de gestion, d’enregistrement et de communication selon l’invention.

Selon un quatrième aspect, l’invention vise aussi un système de vérification comprenant au moins une entité de contrôle, au moins une entité de vérification et au moins une entité de coordination conformes à l’invention.

On peut également envisager, dans d'autres modes de réalisation, que les procédés de contrôle, de traitement, et de configuration ainsi que les entités de contrôle, de vérification et de coordination, et le système de vérification selon l’invention présentent en combinaison tout ou partie des caractéristiques précitées.

D’autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif. Sur les figures :

la représente, dans son environnement, un système de vérification conforme à l’invention, dans un mode particulier de réalisation ;

la représente schématiquement l’architecture matérielle d’un ordinateur pouvant héberger l’une quelconque des entités selon l’invention appartenant au système de vérification de la ;

la représente les différentes étapes des procédés de contrôle, de vérification et de configuration selon l’invention dans un mode particulier de réalisation dans lequel ils sont mis en œuvre par les entités du système de vérification de la ;

la illustre un exemple de modification d’une chaîne de résolution de noms de domaine permettant de mettre en œuvre l’invention.

Description de l’invention

La représente un système 1 de vérification selon l’invention, dans un mode particulier de réalisation.

Dans l’exemple envisagé à la , le système 1 de vérification offre un mécanisme (aussi désigné ici par service ou procédure DYOS, pour « DYnamic Off-Site IP privacy assessment procedure » en anglais) permettant avantageusement d’effectuer des opérations de vérification globale (aussi désignées parfois par opérations d’audit ou opérations d’audit de protection de la vie privée dans ce document), du respect par un service S proposé par un fournisseur de service SP via le réseau Internet, de la protection de la vie privée de ses utilisateurs et en particulier de la confidentialité de leurs données personnelles . La vérification opérée peut être générique et porter sur l’ensemble du service S, ou au contraire être plus spécifique et porter seulement sur une catégorie donnée de flux échangés lors de l’accès à ce service par un utilisateur (ex. ceux générés par une application ou un système d’exploitation particulier, ceux associés à un opérateur particulier, etc.). Une telle vérification peut être avantageusement déclenchée dynamiquement à la demande, par exemple sur requête d’un utilisateur du service S, ou du fournisseur SP du service S, ou encore d’un tiers.

Pour fournir le service S, le fournisseur de service SP s’appuie sur une infrastructure de service hébergée dans un domaine de service SR (ou « Service Realm » en anglais). Par souci de simplification, on considère ici que le domaine de service SR comprend un serveur autoritaire 2 (ou « authoritative server » en anglais) (deuxième dispositif au sens de l’invention) avec lequel, pour accéder au service S, un utilisateur U établit une connexion dite principale (C1) via au moins un équipement utilisateur 3 (premier dispositif au sens de l’invention). Par souci de simplification, dans l’exemple envisagé et décrit par la , on considère que l’utilisateur U utilise un unique équipement utilisateur 3 pour accéder au service S. Toutefois, cette hypothèse n’est pas limitative en soi.

Comme évoqué précédemment, plusieurs serveurs référencés par X dans la , distincts du serveur autoritaire 2, peuvent être par ailleurs sollicités pour la fourniture du service S ; ces serveurs X sont impliqués lors de l’accès au service S dans des connexions dites secondaires (C2), (C2’), … établies avec l’équipement utilisateur 3 en marge de la connexion principale (C1) entre l’équipement utilisateur 3 et le serveur autoritaire 2, pour fournir des services dits « annexes » au service S (ex. résolution de noms de domaine, traçage web). Il en résulte que la connexion établie à proprement parler par l’équipement utilisateur 3 au titre du service S est la combinatoire d’une connexion principale (C1) vers le serveur autoritaire 2 et d’un ensemble de connexions secondaires (C2), (C2’), … vers ces autres serveurs X assurant ces services annexes au service S. Il convient de noter que l’établissement des connexions secondaires est réalisé souvent de manière transparente pour l’utilisateur U.

Pour accéder au réseau Internet et au service S, l’équipement utilisateur 3 peut être connecté directement à un réseau d’un opérateur (ex. réseau d’accès cellulaire ou PLMN (pour « Public Land Mobile Network » en anglais) comme illustré sur la , ou via un réseau local (ou LAN pour « Local Area Network » en anglais) tel qu’un réseau domestique, un réseau d’entreprise, etc., par l’intermédiaire d’un équipement dédié désigné par CPE (pour « Customer Premises Equipment » en anglais).

Aucune hypothèse n’est faite quant à la nature du service S, qui peut par ailleurs s’appuyer sur un domaine de service SR comprenant une pluralité de serveurs (ex. serveur autoritaire, serveurs cache, répartiteurs de charge, etc.) hébergés dans une seule structure (par exemple une infrastructure d’informatique en nuage ou « cloud computing » en anglais) ou un seul équipement, ou dans plusieurs structures ou plusieurs équipements. Un tel service S peut être un service impliquant un système d’exploitation installé sur l’équipement utilisateur 3, ou une application installée sur l’équipement utilisateur 3 (ex. service web HTTP, ou SIP de voix sur IP, ou WebRTC), ou encore un service fourni par un opérateur de réseau, etc. Le service S peut également se trouver dans un autre réseau que le réseau Internet, par exemple dans un réseau d’un opérateur ou dans une infrastructure publique (ex. cloud public ou « public cloud » en anglais).

En outre, aucune limitation n’est attachée à la nature de l’équipement utilisateur 3 utilisé par l’utilisateur U pour accéder au service S. Il peut s’agir d’un équipement fixe ou mobile tel que par exemple un téléphone intelligent (ou « smartphone » en anglais), un ordinateur portable ou fixe, une tablette numérique, etc. Il convient de noter que l’utilisateur U peut être indifféremment une personne physique ou une personne morale (ex. entreprise) ou encore un groupe d’individus (ex. individus rattachés à un même foyer).

Par ailleurs, l’équipement utilisateur 3 peut disposer d’une pluralité d’interfaces de communication lui permettant d’accéder au réseau dans lequel se trouve le domaine de service SR. L’invention s’applique aussi bien à des équipements utilisateur 3 mono-interface que multi-interfaces, quelle que soit la nature de ces interfaces (ex. LAN, WLAN, 3G/4G/5G). De même, un équipement CPE peut être connecté à plusieurs réseaux d’opérateur (contexte dit « multi-homing » en anglais).

On suppose ici qu’un système d’exploitation OS et une ou plusieurs applications APP#i, i=1,…,N, N désignant un entier supérieur ou égal à 1, sont installés et activés sur l’équipement utilisateur 3, et qu’au moins l’une d’entre elles est sollicitée pour accéder au service S. Comme évoqué précédemment, le système d’exploitation OS et/ou la ou les applications APP#i, i=1,…,N, peuvent collecter et partager différents types de données dites de télémétrie ici avec des infrastructures de service impliquées lors la fourniture du service S, que ce soit sur la connexion principale établie par l’équipement utilisateur 3 ou sur les connexions secondaires (C2), (C2’), … établies en marge de cette connexion principale (C1). Ces données de télémétrie comprennent des données de service, mais également des informations d’identification qui peuvent concerner l’équipement utilisateur 3, son réseau d’attachement, ses voisins IP, son routeur par défaut, l’opérateur du réseau auquel il est connecté, etc. et qui exploitées individuellement ou corrélées entre elles peuvent induire ou révéler des précisions sur l’identité de l’utilisateur U.

En outre, d’autres données (assimilées également ici à des données de télémétrie) incluant des informations d’identification peuvent être injectées dans les paquets de données émis par l’équipement utilisateur 3 par des entités des différents réseaux traversés par ces paquets (ex. réseau d’accès) sur les connexions principale (C1) et secondaires (C2), (C2’), …, et ce, sans que l’utilisateur U de l’équipement utilisateur 3 y ait nécessairement consenti. Ces informations d’identification peuvent être ajoutées notamment au niveau applicatif, par exemple dans des entêtes HTTP tels que les entêtes HTTP propriétaires HTTP_MSISDN, HTTP_X_UP_CALLING_LINE_ID, HTTP_X_NOKIA_MSISDN, HTTP_X_HTS_CLID, HTTP_X_MSP_CLID, HTTP_X_NX_CLID, HTTP__RAPMIN, HTTP_X_WAP_MSISDN, HTTP_COOKIE, HTTP_X_UP_LSID, HTTP_X_H3G_MSISDN, HTTP_X_NETWORK_INFO, etc., dans des options TCP (pour « Transmission Control Protocol » en anglais), dans des options IPv4, dans des entêtes d’extension IPv6 (ou « extension headers » en anglais), etc. Il convient de noter que certaines de ces informations d’identification devraient être normalement supprimées par les réseaux traversés, mais les inventeurs ont constaté qu’en pratique, ce n’est pas toujours le cas, et que de telles informations d’identification peuvent être partagées avec des infrastructures tierces (ex. serveurs X introduits précédemment) au même titre que les informations d’identification incluses dans les paquets de données par l’équipement utilisateur 3 lui-même (ex. par son système d’exploitation OS ou par les applications APP#i, i=1,…,N).

Pour auditer le service S (i.e. vérifier que l’usage qui en est fait respecte la vie privée et en particulier la confidentialité des données personnelles de l’utilisateur U), autrement dit pour mettre en œuvre la procédure DYOS proposée par l’invention, le système 1 de vérification s’appuie sur plusieurs entités, à savoir sur :

une entité 4 de contrôle ou PAPc 4 (pour « Privacy Assessment Point control plane » en anglais), conforme à l’invention, et hébergée dans le domaine du service DYOS ;
une ou plusieurs entités 5 de vérification ou PAPd 5 (pour « PAP data plane » en anglais), conformes à l’invention ; et
une entité 6 de coordination du service S ou CAS 6 (pour « Cooperative Audit Server »), conforme à l’invention, et hébergée dans le domaine de service SR. Cette entité 6 de coordination est configurée notamment pour s’interfacer avec l’entité 4 de contrôle et avec l’entité ayant requis l’exécution de la procédure DYOS pour le service S.

Il convient de noter que l’entité 4 de contrôle et tout ou partie des entités 5 de vérification peuvent être co-localisées ou au contraire, hébergées dans des équipements matériels ou logiciels distincts. En outre, des entités 5 de vérification peuvent être déployées en divers endroits, comme par exemple dans le réseau Internet, dans le réseau d’accès au réseau Internet utilisé par l’équipement utilisateur 3 pour accéder au serveur autoritaire 2, dans le domaine de service SR associé au service S, dans le serveur autoritaire 2, etc. Il peut s’agir d’instances virtuelles (i.e. logicielles) activées à la demande, cette activation se faisant préférentiellement en utilisant des mécanismes sécurisés (avec authentification des instances virtuelles) et/ou de contrôle d’intégrité. On peut notamment utiliser à cet effet un mécanisme connu tel que TEEP (pour « Trusted Exécution Environment Provisioning » en anglais) ou RATS (pour « Remote Attestation Procedures Architecture » en anglais).

Dans le mode de réalisation décrit ici, l’entité 4 de contrôle, l’entité 5 de vérification et l’entité 6 de coordination ont l’architecture matérielle d’un ordinateur 7 telle que représentée à la , ou, lorsqu’il s’agit d’instances virtuelles, sont hébergées par des équipements matériels ayant une telle architecture matérielle et exploitent les éléments de cette architecture matérielle.

L’ordinateur 7 comprend notamment un processeur 8, une mémoire vive 9, une mémoire morte 10, une mémoire non volatile 11, et des moyens de communication 12 permettant notamment aux entités du système 1 de vérification de communiquer entre elles et avec d’autres entités comme par exemple avec l’équipement utilisateur 3 ou encore avec des entités sollicitées lors de l’accès au service S par l’équipement utilisateur 3.

La mémoire morte 10 de l’ordinateur 7 constitue un support d’enregistrement conforme à l’invention, lisible par le processeur 8 et sur lequel est enregistré un programme d’ordinateur conforme à l’invention.

Plus spécifiquement, la mémoire morte 10 de l’ordinateur 7 comprend, lorsque ce dernier est ou héberge une entité 4 de contrôle conforme à l’invention, un enregistrement d’un programme d’ordinateur PROG4, comportant des instructions définissant les principales étapes d’un procédé de contrôle selon l’invention.

Ce programme PROG4 définit des modules fonctionnels de l’entité 4 de contrôle qui s’appuient sur ou commandent les éléments matériels 8 à 12 de l’ordinateur 7 cités précédemment. Ces modules comprennent notamment, dans le mode de réalisation décrit ici :

un module 4A de sélection d’au moins une entité 5 de vérification pour analyser tout ou partie des données véhiculées lors de l’accès au service S par l’équipement utilisateur 3. La façon dont est opérée cette sélection est décrite plus en détail ultérieurement en référence aux étapes du procédé de contrôle selon l’invention. On note que plusieurs entités 5 de vérification peuvent être déployées et sélectionnées par l’entité 4 de contrôle pour optimiser l’acheminement des données lors de l’accès au service S mais également leur traitement par les entités de vérification. Par exemple, on peut envisager d’activer une entité 5 de vérification au plus près de l’équipement utilisateur 3 et/ou au plus près du serveur autoritaire 2. En outre, les entités 5 de vérification peuvent être génériques (c-à-d. être configurées pour traiter tout type de service) ou être spécialisées dans le traitement de certains services seulement (et des données de télémétrie relatives à ces services), comme par exemple des entités de vérification spécialisées dans le traitement de données de services impliquant le système d’exploitation OS, ou des entités de vérification spécialisées dans le traitement de données de services impliquant une application APP#i, i=1,…,N (ex. services web HTTP, SIP de voix sur IP, WebRTC), ou encore des entités de vérification spécialisées dans le traitement de données de services offerts par des opérateurs de réseau (et des données de télémétrie injectées par les opérateurs de réseau d’accès), etc. Des mécanismes d’authentification mutuelle comme par exemple TLS (pour « Transport Layer Security » en anglais) peuvent être mis en œuvre entre l’entité 4 de contrôle et la ou les entités 5 de vérification qu’elle a sélectionnées pour l’audit des données émises lors de l’accès au service S par l’utilisateur U ;
un module 4B de déclenchement, configuré pour déclencher auprès de l’entité 6 de coordination du service S, une configuration de ce dernier pour que les données véhiculées sur la connexion principale (C1) et sur au moins une connexion secondaire (C2), (C2’), … établie en marge de cette connexion principale pour la fourniture du service S transitent par la ou les entités 5 de vérification sélectionnées par l’entité 4 de contrôle pour leur permettre d’analyser ces données ; et
un module 4C de notification, configuré pour notifier l’entité 6 de coordination, si un événement déterminé est détecté dans une identité numérique IDNUM(U) de l’utilisateur 3 véhiculée lors de l’accès au service S et comprenant des informations d’identification de l’utilisateur 3 obtenues à partir des données que la ou les entités 5 de vérification ont analysées. L’événement en question peut être par exemple la détection d’une nouvelle information d’identification ou d’une exposition des informations d’identification de l’utilisateur U dépassant un seuil donné, ou encore d’une indication sur l’identité de l’utilisateur résultant de la corrélation de plusieurs informations d’identification mémorisées dans l’identité numérique IDNUM(U). Il peut être détecté par l’entité 4 de contrôle elle-même en examinant l’identité numérique IDNUM(U), ou être signalé à cette dernière par une entité 5 de vérification ou encore par une entité tierce ayant accès à l’identité numérique IDNUM(U) (par exemple, en cas de pluralité d’entités de vérification impliquées dans l’analyse des données émises par l’équipement utilisateur 3, comme évoqué ci-après).

L’identité numérique IDNUM(U) de l’utilisateur U est mémorisée ici dans un espace de stockage 13 partagé par l’entité 4 de contrôle et par la ou les entités 5 de vérification. Il peut s’agir d’un fichier numérique (ex. une base de données) comprenant toutes les informations d’identification relatives à l’utilisateur U détectées par les entités 5 de vérification sur les connexion principale et secondaires auxquelles on souhaite appliquer la procédure DYOS. Ces informations d’identification peuvent être extraites par les entités 5 de vérification des données de télémétrie insérées dans les paquets de données issus de l’équipement utilisateur U dans le cadre de son accès au service S et véhiculés sur les connexions analysées par les entités 5 de vérification, comme décrit plus en détail ultérieurement. Il peut s’agir, comme évoqué précédemment, de tout type d’informations susceptibles de contribuer à l’identification de l’utilisateur, telles que définies notamment en section 5.2.2 du document RFC 6973 précédemment cité. De telles informations d’identification peuvent être liées à un individu particulier ou un groupe d’individus et être utilisées, seules ou en combinaison avec d’autres éléments, pour déduire ou reconnaître l’identité de cet individu ou de ce groupe d’individus. Elles peuvent être de natures diverses et variées ; il peut s’agir notamment d’identifiants à proprement parler de l’utilisateur ou de l’équipement utilisé par ce dernier, mais également d’autres données comme sa localisation ou la localisation de voisins de cet utilisateur, de logs de l’utilisateur sur un ou plusieurs sites, de champs particuliers de messages caractéristiques de l’activation de protocoles de communication, etc. De nombreuses informations sont en effet susceptibles d’apporter des indications sur l’identité de l’utilisateur, seules ou en combinaison avec d’autres informations (ex. localisation GPS, réseau emprunté, etc.).

On note par ailleurs que l’identité numérique IDNUM(U) peut en outre être alimentée par les précisions sur l’identité de l’utilisateur induites par les informations d’identification détectées dans les données analysées par les entités 5 de vérification et/ou résultant de la corrélation de ces informations d’identification entre elles ou avec d’autres éléments. De telles précisions constituent des informations d’identification au sens de l’invention qui peuvent être mémorisées par l’entité qui les obtient (entité 5 de vérification, entité 4 de contrôle ou entité tierce) dans l’identité numérique IDNUM(U) de l’utilisateur U.

Il convient en outre de noter que l’identité numérique IDNUM(U) d’un utilisateur peut résulter de l’analyse des connexions principale et secondaires de plusieurs équipements utilisateur associés à un même utilisateur U et utilisés concomitamment par celui-ci pour accéder au service S. Par ailleurs, l’espace de stockage 13 peut être dédié à un unique utilisateur U ou en variante regrouper les identités numériques de plusieurs utilisateurs distincts, par exemple des utilisateurs connectés à un même réseau local ou d’accès, et permettre ainsi de dériver, à partir de ces identités numériques distinctes, une identité numérique du réseau en question.

A titre illustratif, l’identité numérique IDNUM(U) de l’utilisateur U peut comprendre par exemple tout ou partie des informations d’identification suivantes :

la liste des entités sollicitées lors de l’accès au service S par l’équipement utilisateur 3 pour la connexion principale et les connexions secondaires (incluant les entités de l’infrastructure de service supportant le service S, mais également des autres entités sollicitées lors de cet accès au service, comme par exemple les serveurs X évoqués précédemment) ;
la ou les localisations (ex. GPS (pour Global Positioning System)) de l’équipement utilisateur 3 ;
l’identifiant IMSI (pour « International Mobile Subscriber Identity » en anglais) attribué à l’utilisateur U ;
l’identifiant MSISDN attribué à l’utilisateur U ;
l’identifiant IMEI attribué à l’utilisateur U ;
un identifiant du réseau local auquel l’équipement utilisateur 3 est connecté le cas échéant (ex. adresse MAC de l’équipement CPE) ;
l’identité des visiteurs d’un réseau ;
la ou les adresses IP allouées à l’équipement utilisateur 3 ;
la ou les adresses MAC de l’équipement utilisateur 3 ;
le numéro de la carte SIM associée le cas échéant à l’équipement utilisateur 3 ;
le ou les opérateurs du ou des réseaux d’accès utilisés par l’équipement utilisateur 3 ;
toute autre donnée de télémétrie insérée dans les données issues de l’équipement utilisateur 3 et partagée avec les entités impliquées lors de l’accès au service, et considérée comme étant une information d’identification de l’utilisateur U.

Cette liste n’est bien entendu pas exhaustive, et d’autres éléments peuvent être inclus dans l’identité numérique IDNUM collectée par les entités 5 de vérification. Par exemple, comme évoqué précédemment, l’identité numérique IDNUM peut également comprendre des informations d’identification obtenues à partir des informations d’identification extraites par les entités 5 de vérification (ex. induites par celles-ci ou obtenues en les corrélant entre elles ou avec d’autres éléments).

Les fonctions des modules 4A à 4C de l’entité 4 de contrôle sont détaillées davantage ultérieurement en référence aux étapes du procédé de contrôle selon l’invention.

Lorsque l’ordinateur 7 est ou héberge une entité 5 de vérification conforme à l’invention, la mémoire morte 10 de l’ordinateur 7 comprend un enregistrement d’un programme d’ordinateur PROG5 comportant des instructions définissant les principales étapes d’un procédé de vérification selon l’invention.

Ce programme PROG5 définit des modules fonctionnels de l’entité 5 de vérification qui s’appuient sur ou commandent les éléments matériels 8 à 12 de l’ordinateur 7 cités précédemment. Ces modules comprennent notamment, dans le mode de réalisation décrit ici :

un module 5A de réception, configuré pour recevoir des données véhiculées via la connexion principale (C1) établie entre l’équipement utilisateur 3 et le serveur autoritaire 2 et/ou au moins une dite connexion secondaire (C2), (C2’), … établie en marge de la connexion principale (C1), en fonction des données à analyser confiées à l’entité 5 de vérification ;
un module 5B d’analyse, configuré pour analyser les données reçues afin de déterminer si ces données véhiculent (de manière explicite ou implicite) une ou plusieurs informations d’identification de l’utilisateur U. Différentes configurations du module 5B d’analyse peuvent être envisagées à cet effet de manière alternative ou complémentaire. Ainsi, le module 5B d’analyse peut être configuré préalablement par le fournisseur du service DYOS (typiquement, dans le respect des informations contractuelles qui définissent sa relation avec ses clients) ou par un tiers (par exemple par l’utilisateur de l’équipement client ou par le fournisseur du service S) avec un ensemble de paramètres spécifiques caractérisant des informations d’identification susceptibles d’être véhiculées dans les données échangées lors de l’accès au service S par l’utilisateur U, autrement dit de reconnaître parmi les données analysées de telles informations d’identification ou d’exploiter les données permettant de les obtenir. Par exemple, de tels paramètres peuvent être des entêtes de messages HTTP tels que ceux utilisés par un système d’exploitation (ex. X-Apple-I-SRL-NO, X-Mme-Device-Id, X-Mme-Country, X-Apple-seid) ou des types d’identifiants pouvant être inclus dans le corps des messages véhiculant les données (ex. numéro de série, IMSI, IMEI, identifiant de dispositif ou « device id » en anglais). En variante, le module 5B d’analyse peut être configuré avec des paramètres acquis via l’exécution d’un algorithme d’apprentissage machine (et dont l’exécution peut reposer sur la production et l’exploitation d’un réseau de neurones) permettant de détecter l’existence d’identifiants persistants dans un échange lié au service S, et fournissant pour caractériser la durée de persistance et le type de chaque identifiant persistant ainsi détecté. Les types d’identifiants persistants peuvent être explicitement indiqués dans les messages présentant ces identifiants persistants ou déduits par comparaison avec d’autres types connus d’identifiants (ex. adresse MAC), ou encore résulter d’une configuration par le fournisseur du service DYOS, ou par l’utilisateur de l’équipement client, etc. On note que, quelle que soit la configuration retenue, aucune hypothèse n’est faite quant à l’encodage des informations d’identification recherchées par le module 5B d’analyse ;
un module 5C de mise à jour, activé si le module 5B d’analyse détecte qu’au moins une information d’identification de l’utilisateur U peut être obtenue à partir des données reçues par le module 5A de réception. Le module 5C de mise à jour est configuré pour, en fonction de la ou des informations d’identification obtenues le cas échéant, mettre à jour l’identité numérique IDNUM(U) de l’utilisateur U. Par exemple, le module 5C ajoute les informations d’identification détectées le cas échéant dans les données reçues dans l’identité numérique IDNUM(U) de l’utilisateur U si celles-ci ne sont pas déjà comprises dans l’identité numérique IDNUM(U) ou avec des informations d’identification dérivées par le module 5B d’analyse (ex. induites par les données analysées ou obtenues par corrélation comme évoqué précédemment) ;
un module 5D de transmission configuré pour relayer les données reçues vers leur destinataire (ex. serveur autoritaire 2 pour la connexion principale, ou serveur X pour une connexion secondaire), afin de rendre transparente l’intervention de l’entité 5 de vérification vis-à-vis de l’exécution du service S ; et
un module 5E de vérification (optionnel), configuré pour vérifier si les informations d’identification contenues dans l’identité numérique IDNUM(U) sont conformes à ce qui est attendu pour le service S en termes de confidentialité. Différents contrôles peuvent être mis en œuvre par le module 5E de vérification, par exemple le contrôle de la conformité des informations contenues dans l’identité numérique IDNUM(U) avec les conditions générales d’utilisation (CGU) du service S approuvées par l’utilisateur U, et/ou les contraintes en la matière imposées par la réglementation en vigueur (ex. règlement RGPD de l’Union Européenne), ou encore les déclarations faites par les fournisseurs du service S et des services annexes au service S, fournis via les connexions secondaires, etc. Le module 5E de vérification est avantageusement configuré pour signaler, par exemple à l’entité 4 de contrôle, s’il détecte une non-conformité.

Les fonctions des modules 5A à 5E de chaque entité 5 de vérification impliquée dans la procédure DYOS sont détaillées davantage ultérieurement en référence aux étapes du procédé de vérification selon l’invention.

Lorsque l’ordinateur 7 est ou héberge une entité 6 de coordination conforme à l’invention, la mémoire morte 10 de l’ordinateur 7 comprend un enregistrement d’un programme d’ordinateur PROG6 comportant des instructions définissant les principales étapes d’un procédé de configuration selon l’invention.

Ce programme PROG6 définit des modules fonctionnels de l’entité 6 de coordination du service S qui s’appuient sur ou commandent les éléments matériels 8 à 12 de l’ordinateur 7 cités précédemment. Ces modules comprennent notamment, dans le mode de réalisation décrit ici :

un module 6A de communication lui permettant de s’interfacer avec l’entité 4 de contrôle selon l’invention ; et
un module 6B de configuration, activé sur réception d’une requête de l’entité 4 de contrôle reçue par le module 6A de communication, et programmé pour configurer le service S et plus particulièrement l’infrastructure de service supportant le service S et/ou l’équipement client 3, pour que les données éligibles à la procédure DYOS et véhiculées sur la connexion principale (C1) et sur la ou les connexions secondaires (C2), (C2’),… établies en marge de la connexion principale (C1), transitent par la ou les entités 5 de vérification sélectionnées par l’entité 4 de contrôle pour analyser ces données. Le module 6B de configuration peut, pour inclure une telle entité 5 de vérification dans le chemin des données émises par l’utilisateur U, procéder de différentes façons. Il peut par exemple déclencher une modification d’un mécanisme de résolution de noms de domaine (mécanisme DNS) pour y inclure une information de joignabilité (ex. adresse IP) de l’entité 5 de vérification en question. Il peut également activer (dans le réseau) un mécanisme de chaînage de service (ou SFC) invoquant l’entité 5 de vérification en question dans le chemin des données échangées lors de l’accès au service S par l’utilisateur U. Il peut aussi rediriger les données relatives aux connexions concernées vers l’entité 5 de vérification ou activer un mécanisme de routage à la source (c’est-à-dire à partir de l’équipement client 3) vers l’entité 5 de vérification (ex. l’équipement client 3 est configuré par le module 6B de configuration pour inclure parmi les entités intermédiaires traversées par les messages qu’il envoie la ou les entités 5 de vérification). Ces mécanismes peuvent être utilisés de façon alternative ou complémentaire.

Les fonctions des modules 6A et 6B de l’entité 6 de coordination du service S sont détaillées davantage ultérieurement en référence aux étapes du procédé de configuration selon l’invention.

Nous allons maintenant décrire, en référence à la , la procédure (service) DYOS telle qu’elle est mise en œuvre par le système 1 de vérification de la , dans un mode particulier de réalisation. Cette procédure sollicite chaque entité du système 1 de vérification et plus particulièrement déclenche l’exécution, par l’entité 4 de contrôle, d’un procédé de contrôle selon l’invention (étapes E00 à E60), par chaque entité 5 de vérification sélectionnée par l’entité 4 de contrôle, d’un procédé de vérification selon l’invention (étapes G10 à G70), et par l’entité 6 de coordination, d’un procédé de configuration selon l’invention (étapes F10 à F40).

Dans le mode de réalisation décrit ici, on suppose que durant une phase préliminaire d’activation du service DYOS (étape E00/F00), un accord a été mis en place entre le fournisseur du service DYOS, qui gère notamment l’entité 4 de contrôle et les entités 5 de vérification, et le fournisseur SP du service S. Cet accord peut être statique ou mis en place en utilisant un mécanisme connu tel que CPNP.

Il résulte de cet accord le maintien par le fournisseur SP du service S d’une table ou de façon équivalente d’une base de données (référencée par 14 sur la ) dans le domaine de service SR répertoriant les entités de contrôle autorisées à mettre en œuvre la procédure DYOS pour le service S. Dans l’exemple envisagé ici, la table 14 répertorie pour le service S l’entité 4 de contrôle (PAPc 4) du système 1 de vérification. Elle est accessible par l’entité 6 de coordination du système 1 de vérification (ou par les entités 6 de coordination s’il y en a plusieurs).

Par ailleurs, du côté du fournisseur du service DYOS, la ou les entités de contrôle autorisées à mettre en œuvre la procédure DYOS maintiennent une table ou de façon équivalente une base de données (référencée par 15 sur la ) répertoriant la ou les entités de coordination avec lesquelles s’interfacer pour chaque service à auditer. Dans l’exemple du service S envisagé ici, on suppose que la table 15 répertorie pour le service S l’entité 6 de coordination (CAS 6) du système 1 de vérification et que cette table 15 est accessible par l’entité 4 de contrôle chargée de mettre en œuvre la procédure DYOS pour le service S.

La table 15 contient en outre diverses informations descriptives de la ou des entités de coordination du service S, comme notamment une ou plusieurs informations de joignabilité (ex. adresses IP), un ou plusieurs noms de domaine auxquels sont rattachées la ou les entités de coordination, un ou plusieurs protocoles de transport supportés par la ou les entités de coordination (ex. TCP (pour « Transmission Control Protocol » en anglais), TLS, QUIC, DTLS (pour « Datagram TLS » en anglais), etc.), un ou plusieurs protocoles de la couche application du modèle OSI supportés par la ou les entités de coordination (ex. HTTP, etc.), etc. Ces informations ont pour objectif de permettre à l’entité 4 de contrôle de garantir que la procédure DYOS est exécutée dans les conditions de fourniture du service S.

Suite à cette phase préliminaire, l’entité 4 de contrôle désignée pour mettre en œuvre la procédure DYOS sélectionne les connexions (Cx) à auditer impliquées dans la fourniture du service S à l’utilisateur U via son équipement utilisateur 3 (étape E10).

Cette sélection peut se faire de façon aléatoire ou de façon ciblée, en fonction notamment du réseau d’accès utilisé pour accéder au service (ex. du numéro de système autonome dont fait partie le réseau d’accès), de la zone géographique dans laquelle se situe l’équipement utilisateur U, etc. Elle peut être programmée ou déclenchée par une demande explicite de l’administrateur de l’entité de contrôle (ex. fournisseur du service DYOS), ou un événement externe comme par exemple la notification d’un changement des conditions générales d’utilisation (CGU) du service S.

On suppose ici que lors de l’étape E10, la connexion principale (C1) et l’ensemble des connexions secondaires (C2), (C2’), … établies en marge de la connexion principale (C1) lors de l’accès au service S par l’utilisateur U via son équipement utilisateur 3, sont sélectionnées par l’entité 4 de contrôle pour faire l’objet de la procédure DYOS.

En variante, seulement une partie des connexions établies lors de l’accès au service S peuvent être sélectionnées lors de cette étape E10.

Puis l’entité 4 de contrôle détermine la ou les entités de coordination avec lesquelles s’interfacer pour mettre en œuvre la procédure DYOS au vu des connexions sélectionnées (étape E20). A cet effet, l’entité 4 de contrôle consulte ici la table 15 et les informations caractérisant les entités de coordination du service S disponibles répertoriées dans cette base, en fonction des caractéristiques des connexions à auditer (ex. protocole de transport, protocole de la couche application, etc.). On suppose ici qu’à l’issue de l’étape E20, l’entité 4 de contrôle sélectionne l’entité 6 de coordination du service S.

L’entité 4 de contrôle envoie alors à l’entité 6 de coordination du service S, en utilisant l’information de joignabilité et les autres informations consignées dans la table 15 (ex. protocole de transport, protocole de la couche application, etc.), une demande REQ de connexion visant à mettre en place la procédure DYOS pour les connexions sélectionnées lors de l’étape E10 (étape E30).

L’entité 6 de coordination reçoit via son module 6A de communication la demande REQ de connexion de l’entité 4 de contrôle et la traite (étape F10). Plus particulièrement, lors de ce traitement, le module 6A de communication vérifie dans la table 14 si l’entité 4 de contrôle est autorisée à mettre en œuvre la procédure DYOS pour le service S. Une authentification de l’entité 4 de contrôle peut par ailleurs être mise en œuvre selon des conditions prévues le cas échéant lors de la phase préliminaire E00/F00 (par exemple à l’aide de certificats échangés lors de cette phase préliminaire ou d’autres mécanismes connus tels que PSK (pour « Pre-Shared Keys »)). En cas d’échec de l’autorisation et/ou de l’authentification de l’entité 4 de contrôle, la demande REQ de connexion de l’entité 4 de contrôle est rejetée par l’entité 6 de coordination.

Dans l’exemple envisagé ici, comme mentionné précédemment, l’entité 4 de contrôle est répertoriée dans la table 14 comme étant autorisée à mettre en œuvre la procédure DYOS pour le service S. L’entité 6 de coordination accepte donc la demande REQ formulée par l’entité 4 de contrôle de procéder selon la procédure DYOS à l’analyse des données véhiculées lors de l’accès au service S par l’équipement utilisateur 3 (étape F20). Elle peut en outre, lors de l’acceptation de la demande REQ, fournir à l’entité 4 de contrôle une ou plusieurs contraintes du service S à prendre en compte pour l’exécution de la procédure DYOS. Une telle contrainte est par exemple un délai de détour maximum autorisé, une zone géographique dans laquelle doivent être déployées les entités de vérification impliquées dans la procédure DYOS, le numéro du système autonome dans lequel doivent se trouver les entités de vérification impliquées dans la procédure DYOS, etc. On note que la fourniture de cette ou de ces contraintes de service lors de l’acceptation de la demande est optionnelle. En variante, cette ou ces contraintes de service peuvent être échangées avec le fournisseur du service S lors de la phase préliminaire E00/F00 d’activation du service DYOS.

L’acceptation par l’entité 6 de coordination de la mise en place de la procédure DYOS déclenche au niveau de l’entité 4 de contrôle la sélection d’une ou de plusieurs entités 5 de vérification pour mener la procédure DYOS, et plus particulièrement pour analyser les données échangées sur les connexions sélectionnées lors de l’étape E10 (étape E40).

Cette sélection est opérée par le module 4A de sélection de l’entité 4 de contrôle en tenant compte de la ou des contraintes de service transmises par l’entité 6 de coordination lors de l’étape F20 ou préconfigurées lors de la phase préliminaire E00/F00 d’activation. On suppose ici par souci de simplification, qu’une seule entité 5 de vérification est sélectionnée pour traiter les données véhiculées sur la connexion principale (C1) et sur les connexions secondaires (C2), (C2’), ...

Cette hypothèse n’est toutefois pas limitative en soi, et plusieurs entités 5 de vérification vérifiant les contraintes de service du service S peuvent être sélectionnées, comme par exemple, une entité de vérification distincte par connexion à auditer. En outre, plusieurs entités de vérification peuvent être déployées en divers endroits du ou des réseaux traversés par les connexions à auditer (ex. au plus près de l’équipement utilisateur 3 ou de certains réseaux, proche du serveur autoritaire 2, etc.)

Suite à la sélection de l’entité 5 de vérification par le module 4A de sélection, l’entité 4 de contrôle communique dans un message adressé à l’entité 6 de coordination au moins une information de joignabilité de cette entité 5 de vérification, telle que son adresse IP et un nom de domaine correspondant (ex. « example.com ») (étape E50). Ce nom de domaine peut être avantageusement utilisé pour des besoins d’authentification, notamment pour émettre des certificats de sécurité comme décrit ci-après.

L’entité 6 de coordination peut alors, à partir de ces informations, déléguer (fournir) un nom de « sous-domaine » (ex. « audit.example.com ») et émettre un certificat pour l’entité 5 de vérification sélectionnée (pouvant être utilisé par exemple pour déchiffrer les données à analyser le cas échéant, sécuriser ses échanges avec les infrastructures impliquées lors de la fourniture du service S, ou encore vérifier que les données qui lui parviennent pour analyse sont bien éligibles à la procédure DYOS). Cette étape est toutefois optionnelle.

La réception du message de l’entité 4 de contrôle déclenche également la configuration par l’entité 6 de coordination, via son module 6B de configuration, de la chaîne de service impliquée dans la fourniture du service S à l’équipement utilisateur 3 pour inclure l’entité 5 de vérification sélectionnée par l’entité 4 de contrôle (ou le cas échéant, les entités de vérification sélectionnées), dans le chemin des données échangées lors de l’accès au service S par l’équipement utilisateur 3 et qui doivent être auditées via la procédure DYOS (étape F30). Comme mentionné précédemment, ceci peut être réalisé de différentes manières par le module 6B de configuration (qui peut être amené à configurer différentes entités impliquées directement ou indirectement dans la fourniture du service S, comme par exemple le serveur autoritaire 2, le serveur DNS nominal utilisé par l’équipement utilisateur 3, l’équipement utilisateur 3, etc.) : modification de la chaîne de résolution de noms de domaines (DNS) pour inclure une information de joignabilité (ex. adresse IP) de l’entité 5 de vérification, activation d’un mécanisme SFC de chaînage de service impliquant l’entité 5 de vérification, redirection des données véhiculées par les connexions à auditer vers l’entité 5 de vérification (par exemple configurant le serveur DNS nominal de l’équipement utilisateur 3 pour qu’il inclue l’information de joignabilité de l’entité 5 de vérification dans ses réponses aux requêtes DNS émises par l’équipement utilisateur 3), routage à la source via l’entité 5 de vérification, etc.

Plus précisément, la modification de la chaîne DNS vise à inclure l’entité 5 de vérification dans la chaîne DNS, afin que l’entité 5 de vérification puisse identifier les connexions secondaires (C2), (C2’), … établies en marge de la connexion principale (C1) et auditer les données transmises via ces connexions secondaires. Pour inclure l’entité 5 de vérification dans la chaîne DNS sollicitée lors de l’invocation du service S, l’entité 6 de coordination peut, dans un mode particulier de réalisation, communiquer au serveur autoritaire 2 (entité impliquée dans la fourniture du service au sens de l’invention) l’information de joignabilité (ex. adresse IP) de l’entité 5 de vérification, pour qu’il indique à l’équipement utilisateur 3, par exemple en réponse à un message d’invocation du service S émis par l’équipement utilisateur 3 (requête d’accès au service ou requête envoyée ultérieurement durant la consommation du service à proprement parler), d’envoyer ses requêtes de résolution de noms de domaine dans le cadre du service S à l’entité associée à cette information de joignabilité, autrement dit à l’entité 5 de vérification. Cette indication peut être transmise dans un entête dédié du message de réponse, par exemple dans un entête appelé DNS_RESOLVER défini pour les besoins de l’invention. De la sorte, l’entité 5 de vérification est en mesure de recevoir les connexions secondaires (C2), (C2’), … établies en marge de la connexion principale (C1) afin de pouvoir analyser les données véhiculées sur ces connexions secondaires. Il convient de noter que si plusieurs entités de vérification sont désignées par l’entité 4 de contrôle, l’entête DNS_RESOLVER contient les informations de joignabilité de chacune des entités de vérification désignées, éventuellement complétées par une indication concernant les requêtes DNS à envoyer vers telle ou telle entité de vérification.

La illustre un exemple de réalisation de ce qui vient d’être décrit (redirection du trafic et modification de la chaîne DNS) lorsque le protocole HTTP est utilisé et une seule entité 5 de vérification est sélectionnée par l’entité 4 de contrôle.

Dans cet exemple, l’équipement utilisateur 3 adresse une requête DNS, désignée par QUERY(2), à son serveur DNS nominal DNS-NOM en vue d’accéder au service S fourni par le serveur autoritaire 2 (étape H10). Le serveur DNS nominal DNS-NOM lui répond en fournissant une adresse IP, notée @IP5, de l’entité 5 de vérification (étape H20).

L’équipement utilisateur 3 envoie alors une requête HTTP POST d’accès au service S destinée au serveur autoritaire 2 (renseigné par exemple dans le champ SNI (pour « Server Name Indication » en anglais) ou ESNI lorsque le protocole TLS est utilisé pour établir des connexions dans le cadre du service S) en utilisant comme adresse destination l’adresse IP @IP5 qui lui a été transmise (étape H30). Ceci permet de s’assurer que la requête HTTP POST associée transite par l’entité 5 de vérification qui peut alors analyser les données véhiculées via cette connexion (incluant la requête POST). Cette requête est ensuite relayée par l’entité 5 de vérification vers son destinataire originel, à savoir ici le serveur autoritaire 2 (étape H40).

Le serveur autoritaire 2 traite et répond à la requête d’accès de l’équipement utilisateur 3, de façon connue en soi. Il insère par ailleurs dans cette réponse l’entête DNS_RESOLVER contenant l’adresse IP @IP5 de l’entité 5 de vérification et indiquant à l’équipement utilisateur 3 d’envoyer ses futures requêtes DNS vers l’entité 5 de vérification associée à cette adresse IP @IP5 ; cette réponse transite via l’entité 5 de vérification (étapes H50 et H60).

Sur réception de cette indication, l’équipement utilisateur 3 adresse ses futures requêtes DNS (QUERY(X)) envoyées dans le cadre du service S à l’entité 5 de vérification (et non plus à son serveur DNS nominal DNS-NOM), qui peut ainsi s’assurer d’être en coupure de flux des connexions secondaires établies par l’équipement utilisateur 3 dans le cadre de ce service (étapes H70, H80).

En variante, on peut envisager que ce soit une autre entité qui communique à l’équipement utilisateur l’entête DNS_RESOLVER, comme par exemple, les entités de vérification elles-mêmes lorsqu’elles reçoivent des données associées à l’équipement utilisateur 3, suite à une configuration appropriée de cet équipement, par exemple par le fournisseur du service DYOS.

En référence de nouveau à la , une fois la configuration du service S réalisée par le module 6B de configuration de l’entité 6 de coordination, l’entité 5 de vérification se trouve sur les chemins empruntés par les données associées aux connexions principale et secondaires de l’équipement utilisateur 3 visées par la procédure DYOS. Autrement dit, toutes les données émises par l’équipement utilisateur 3 dans le cadre de ces connexions transitent maintenant par l’entité 5 de vérification.

A réception d’un paquet de données (étape G10), l’entité 5 de vérification vérifie si le paquet de données en question appartient bien à une connexion qu’il doit analyser (par exemple, à partir du champ « adresse source » du paquet) (étape G20). Si ce n’est pas le cas, le paquet de données est supprimé.

Si c’est le cas, l’entité 5 de vérification procède, via son module 5B d’analyse, à l’analyse des données contenues dans le paquet selon le paramétrage avec lequel il a été configuré pour le service S, et à la recherche d’informations d’identification parmi ces données ou pouvant être dérivées de ces données (étape G30). Il peut si besoin lors de cette étape procéder au déchiffrement des données contenues dans le paquet si celles-ci sont chiffrées. Lors de cette étape d’analyse, le module 5B d’analyse recherche par exemple les identifiants avec lesquels il a été configuré, ou si de nouvelles plateformes de collecte de données sont impliquées, ou encore fournit à son algorithme d’apprentissage machine les données du paquet pour la recherche et l’identification d’identifiants persistants parmi ces données. L’analyse des données contenues dans le paquet conduite par le module 5B d’analyse dépend bien entendu de son paramétrage. Le module 5B peut également, selon ce paramétrage, identifier des informations d’identification induites par les données, ou corréler des données entre elles ou avec d’autres éléments pour identifier de telles information d’identification, etc.

On note que, lorsque la procédure DYOS est déclenchée par un acteur autre que le fournisseur du service DYOS, comme par exemple l’utilisateur U, alors préférentiellement une procédure est mise en œuvre pour sécuriser ce paramétrage et s’assurer que ledit acteur est habilité à effectuer ce paramétrage. Une telle procédure peut être la suivante : l’utilisateur U contacte via son équipement client 3 l’entité 4 de contrôle et partage avec elle un identifiant ID unique, tel qu’un condensé (ou « hash » en anglais) d’un certificat échangé avec l’entité 4 de contrôle, ou les x premiers bits de ce condensé (par exemple x=16)), ce condensé pouvant être par exemple calculé selon le mécanisme SHA (pour « Secure Hash Algorithm » en anglais)-256 connu en soi. L’entité 4 de contrôle communique cet identifiant ID unique à l’entité 6 de coordination lors de l’étape E50 décrite précédemment, qui déclenche lors de l’étape F30 la configuration de la chaîne de service impliquée dans la fourniture du service S pour l’équipement client 3 identifié par cet identifiant unique ID. Cet identifiant unique ID est par ailleurs utilisé par chaque connexion principale et secondaire pour identifier l’équipement client 3.

Lors de l’étape G30 d’analyse des données véhiculées dans le paquet reçu, si le module 5B d’analyse identifie des informations d’identification de l’utilisateur U (ex. identifiants spécifiques de son équipement utilisateur 3 ou autres données sensibles, localisation, etc. extraites des données ou induites par celles-ci), le module 5C de mise à jour de l’entité 5 de vérification met alors à jour l’identité numérique IDNUM(U) en fonction des informations d’identification détectées (étape G40). Plus particulièrement, dans le mode de réalisation décrit ici, il consulte l’identité numérique IDNUM(U) de l’utilisateur U pour déterminer si les informations d’identification détectées sont déjà présentes dans l’identité numérique IDNUM(U), et si ce n’est pas le cas, il ajoute à l’identité numérique IDNUM(U) les nouvelles informations d’identification détectées.

Puis l’entité 5 de vérification, via son module 5D de transmission, relaie le paquet de données reçu et analysé vers l’entité destinataire de ce paquet (serveur autoritaire 2 s’il s’agit d’un paquet émis sur la connexion principale (C1) ou serveur X s’il s’agit d’un paquet émis sur une connexion secondaire (C2), (C2’), …) (étape G50). Ceci permet de s’assurer que l’intervention de l’entité 5 de vérification est transparente pour le service S.

On note que selon le mécanisme mis en œuvre pour impliquer l’entité 5 de vérification dans le chemin des données des connexions établies par l’équipement utilisateur 3 lors de l’accès au service, une encapsulation des données peut s’avérer nécessaire par le module 5D de transmission, typiquement lorsqu’un tunnel est activé entre l’entité 5 de vérification et le destinataire du paquet de données. Cette encapsulation peut s’appuyer sur diverses procédures connues de l’homme du métier, comme par exemple IPsec, TLS, QUIC, GRE (pour « Generic Routing Encapsulation » en anglais), DTLS, etc.

Dans le mode de réalisation décrit ici, l’entité 5 de vérification est chargée en outre, via son module 5E de vérification, de vérifier si les informations d’identification nouvellement détectées et/ou l’identité numérique IDNUM(U) ne comportent pas des événements qu’il convient de signaler au fournisseur du service DYOS, par l’intermédiaire de l’entité 4 de contrôle.

Un tel événement est par exemple :

la découverte, à partir des données analysées par le module 5E de vérification, d’une nouvelle plateforme de collecte de données impliquée lors de l’accès au service S. L’identification du type de la plateforme de collecte de données ainsi découverte peut être statique, par exemple à partir d’une liste maintenue et établie par le fournisseur du service DYOS, ou au contraire dynamique, via la détection de connexions récurrentes vers des noms de domaines donnés. S’il dispose d’une adresse IP pour cette nouvelle plateforme, le module 5E de vérification peut interroger une base de données (ex. base WHOIS) pour résoudre l’identité de la plateforme associée à cette adresse IP ;
un niveau d’exposition de tout ou partie des informations d’identification de l’utilisateur U supérieur à un seuil donné. Un tel niveau d’exposition peut être estimé par le module 5E de vérification pour l’utilisateur U en considérant un encodage de bits particulier associant un certain nombre de bits aux informations d’identification de sorte à caractériser leur contribution à l’identification de l’utilisateur U. Une telle approche permet avantageusement de mesurer de façon unifiée et globale l’exposition d’un utilisateur au travers des informations d’identification détectées. Il convient de noter que même si les informations d’identification ne révèlent pas elles-mêmes en soi directement l’identité de l’utilisateur U (i.e. ne sont pas des informations de type PII, pour « Personally Identifiable Information » en anglais), d’autres informations (ex. localisation GPS) véhiculées dans des paquets de données émis par l’équipement utilisateur 3 de l’utilisateur U couplées à ces informations d’identification peuvent permettre d’établir des profils uniques, et donc in fine de tracer l’utilisateur U. Ainsi, selon cet encodage particulier, plus le nombre de bits nécessaires pour caractériser le niveau d’exposition est grand, plus la probabilité d’identifier l’utilisateur est moindre. A titre d’exemple nullement limitatif, un niveau d’exposition codé sur 32 bits est meilleur qu’un niveau d’exposition codé sur 16 bits ;
une nouvelle information d’identification de l’utilisateur U détectée par l’entité 5 de vérification dans les données qu’elle vient d’analyser ;
une information d’identification de l’utilisateur U transmise à une entité tierce qui ne respecte pas les CGU approuvées par l’utilisateur U, ou une réglementation en vigueur en matière de confidentialité (ex. règlement RGPD de l’Union Européenne), ou encore une déclaration faite par le fournisseur du service S indiquant sa politique en matière de collecte d’informations d’identification et le ou les traitements opérés sur les informations d’identification collectées (ex. stockage, partage), etc. ;
etc.

Sur détection d’un tel événement, le module 5E de vérification envoie un signalement de l’événement au fournisseur du service DYOS et plus particulièrement ici, à l’entité 4 de contrôle.

Outre la conformité des informations d’identification détectées sur la connexion principale avec la déclaration du fournisseur de service S, dans le mode de réalisation décrit ici, l’entité 5 de vérification, via son module 5E de vérification, est également configurée pour examiner les informations d’identification véhiculées sur chaque connexion secondaire qu’elle gère (c’est-à-dire qu’elle audite) et pour déterminer si ces informations d’identification et le traitement qui en est fait par les infrastructures collectant ces informations d’identification sont conformes aux déclarations faites par les opérateurs de ces infrastructures, autrement dit conformes aux politiques de collecte et de traitement d’informations annoncées par ces opérateurs.

A cet effet, on suppose dans le mode de réalisation décrit ici, que ces politiques sont publiées en utilisant une URI de type « well-known » telle que décrite dans le document IETF RFC 8615, et appelée par exemple ici « telemetry-claims ». Le module 5E de vérification est alors en mesure de récupérer, en envoyant une requête (ex. requête HTTP GET) à cette URI, lesdites politiques en question pour chaque service annexe au service S invoqué dans une connexion secondaire (C2), (C2’), …, établie en marge de la connexion principale (C1), et ainsi obtenir la liste des informations d’identification et les traitements opérés le cas échéant selon ces politiques. On suppose ici que le corps du message de réponse ciblant ladite URI, reçu par le module 5E de vérification, comprend un objet structuré selon un format JSON (pour « JavaScript Object Notation » en anglais), identifié par un nouvel identifiant « media-type » appelé par exemple « application/telemetry-claims », et indiquant les données collectées et utilisées par l’infrastructure du service annexe concerné, quel(s) traitement(s) est/sont appliqué(s) le cas échéant sur les données (ex. si ces données sont enregistrées), etc. L’objet JSON peut également indiquer si un organisme d’audit a déjà certifié ces indications, et le cas échéant, donner l’identité de l’organisme en question ainsi qu’un lien vers le rapport d’audit établi par cet organisme. On peut noter que l’organisme en question peut être le fournisseur du service DYOS lui-même, auquel cas l’entité 5 de vérification a un accès direct au rapport d’audit dans le mode de réalisation décrit ici. L’audit en question peut être un audit sur site (ex. au niveau d’un serveur X selon la connexion considérée) ou une procédure DYOS précédemment exécutée et impliquant l’infrastructure du service annexe considéré.

Le module 5E de vérification vérifie alors, pour chaque connexion dont il est chargé, la conformité des informations d’identification véhiculées sur cette connexion avec les informations d’identification et les traitements déclarés qu’il a obtenus en ciblant les URI « well-known ». S’il n’y a pas conformité, il le signale à l’entité 4 de contrôle.

On note que le module 5E de vérification peut également corréler les déclarations et les informations d’identification qu’il a détectées avec les audits précédemment réalisés le cas échéant et signaler toute déviation par rapport aux déclarations. Il peut également, si un audit a déjà été réalisé dans le cadre de la procédure DYOS, modifier et/ou compléter dynamiquement le rapport d’audit correspondant. Il peut également enregistrer localement une alarme pour ce service.

L’entité 4 de contrôle relaie chaque signalement reçu de l’entité 5 de vérification à l’entité 6 de coordination (étape E60), afin que des mesures soient prises si nécessaire en fonction de l’événement signalé (ex. information de l’utilisateur U, (étape F40).

En variante, on peut envisager un signalement à d’autres entités, comme par exemple à l’équipement utilisateur 3, etc.

Dans le mode de réalisation qui vient d’être décrit, les vérifications exécutées dans le cadre de l’audit sont mises en œuvre par le module 5E de l’entité 5 de vérification. Dans un autre mode de réalisation, tout ou partie de ces vérifications peuvent être mises en œuvre par une autre entité du système 1 de vérification, comme par exemple l’entité 4 de contrôle. Un tel mode de réalisation est avantageux notamment lorsque le système 1 de vérification comprend plusieurs entités 5 de vérification alimentant l’identité numérique IDNUM(U) et gérées par une même entité 4 de contrôle.

On note que la procédure DYOS qui vient d’être décrite permet de réaliser un audit non seulement de la connexion principale établie pour accéder à un service, mais également les connexions secondaires établies en marge de cette connexion principale, et ce, en différents points de ces connexions. Elle peut être combinée à un audit sur site, réalisé par exemple au niveau du serveur autoritaire fournissant le service en question. La procédure DYOS proposée par l’invention permet ainsi un audit global du service S permettant de valider ou d’invalider le respect par ce service et par les services sous-jacents (annexes) sollicités pour accéder à ce service, des données personnelles d’un utilisateur.

En outre, la procédure DYOS peut être mise en œuvre de façon récursive. Ainsi, la procédure qui vient d’être décrite s’applique aussi à chaque connexion secondaire établie en complément (c’est-à-dire en marge) de la connexion principale, pour les connexions établies en complément de ladite connexion secondaire (désignées ensuite par connexions de niveau supérieur), puis à partir de chaque connexion de niveau supérieur établie en complément de chaque connexion secondaire, etc. Pour mieux décrire ce cas de figure, on désigne ci-après par « connexion de niveau N » la connexion principale et « connexions de niveau N+1 » les connexions secondaires établies en complément de la connexion principale, puis « connexions de niveau N+2 », les connexions secondaires établies en complément de chaque connexion de niveau N+1, etc. et plus généralement « connexions de niveau N+x » les connexions établies en complément des connexions de niveau N+(x-1). Pour gérer un tel cas de figure, on peut appliquer de façon récursive la procédure qui vient d’être décrite à une connexion du niveau N+(x-1) (considérée comme connexion principale) et aux connexions du niveau N+x établies en complément de cette connexion (considérées dans la procédure DYOS comme des connexions secondaires de la connexion principale de niveau N+(x-1)). Le mécanisme d’audit proposé par la procédure DYOS peut ainsi avantageusement s’appliquer à l’ensemble des connexions (c-à-d., toutes les connexions du niveau N au niveau N+(x-1)). L’identité numérique de l’utilisateur prise en compte pour l’audit réalisé par la procédure DYOS peut alors tenir compte de l’ensemble des informations d’identification collectées à tous les niveaux considérés.

Dans le mode de réalisation décrit ici, on a considéré une architecture du système 1 de vérification s’appuyant sur une entité de coordination et sur une entité de contrôle. Toutefois, il est possible également d’avoir plusieurs entités de coordination et plusieurs entités de contrôle. Par ailleurs, une même entité de vérification peut être gérée par plusieurs entités de contrôle.

Claims

Procédé de contrôle d’une vérification opérée sur des données véhiculées dans au moins un réseau de communication lors d’un accès par un premier dispositif (3) d’un utilisateur (U) à un service (S) fourni par un deuxième dispositif (2) via une connexion dite principale ((C1)) établie entre le premier et le deuxième dispositif, ledit procédé étant destiné à être mis en œuvre par une entité (4) de contrôle et comprenant :
une étape (E50) de déclenchement, auprès d’une entité (6) de coordination, d’une configuration du service pour que des données véhiculées sur ladite connexion principale et sur au moins une connexion secondaire ((C2),(C2’)) établie en marge de ladite connexion principale ((C1)) pour la fourniture du service transitent par au moins une entité (5) de vérification sélectionnée par ladite entité (4) de contrôle pour analyser lesdites données ; et

une étape (E60) de notification de ladite entité (6) de coordination, si un événement déterminé est détecté dans une identité numérique (IDNUM(U)) dudit utilisateur véhiculée lors de l’accès audit service et comprenant des informations d’identification de l’utilisateur obtenues à partir desdites données analysées par ladite au moins une entité de vérification.
Procédé de contrôle selon la revendication 1 dans lequel ladite étape de déclenchement est conditionnée par une acceptation (F20) préalable de ladite entité (6) de coordination de procéder à l’analyse desdites données.
Procédé de contrôle selon la revendication 1 ou 2 comprenant une étape (E40) de sélection de ladite au moins une entité (5) de vérification en fonction d’au moins une contrainte dudit service prédéterminée ou transmise par ladite entité (6) de coordination.
Procédé de contrôle selon l’une quelconque des revendications 1 à 3 dans lequel l’étape de déclenchement (E50) comprend une fourniture à ladite entité (6) de coordination d’une information de joignabilité (@IP5) de ladite au moins une entité (5) de vérification.
Procédé de traitement, par une entité (5) de vérification, de données véhiculées sur au moins un réseau de communication lors d’un accès par un premier dispositif (3) d’un utilisateur (U) à un service (S) fourni par un deuxième dispositif (2) via une connexion dite principale ((C1)) établie entre le premier et le deuxième dispositif, au moins une connexion dite secondaire ((C2),(C2’)) étant établie en marge de ladite connexion principale lors de la fourniture dudit service, ledit procédé comprenant :
une étape (G10) de réception de données véhiculées via ladite connexion principale et/ou au moins une dite connexion secondaire ;

si au moins une information d’identification de l’utilisateur est obtenue à partir desdites données reçues, en fonction de ladite au moins une information d’identification obtenue, une étape (G40) de mise à jour d’une identité numérique de l’utilisateur véhiculée lors de l’accès audit service ; et

une étape (G50) de relai desdites données vers un destinataire desdites données.
Procédé de traitement selon la revendication 5 comprenant une étape (G30) d’analyse des données reçues pour déterminer si elles véhiculent au moins une information d’identification de l’utilisateur, ladite étape d’analyse (G30) utilisant au moins un paramètre avec lequel ladite entité (5) de vérification a été préalablement configurée et/ou qu’elle a acquis via une exécution d’un algorithme d’apprentissage machine.
Procédé de traitement selon la revendication 5 ou 6 comprenant en outre :
une étape (G60) d’obtention d’une liste d’informations d’identification déclarées comme étant véhiculées lors de l’accès audit service et/ou un ou des traitements appliqués à ladite liste d’informations d’identification ;

une étape (G60) de vérification de la conformité de l’identité numérique de l’utilisateur à ladite liste et/ou au(x)dit(s) traitement(s) obtenu(s) ; et

une étape (G70) de signalement en cas de non-conformité.
Procédé de traitement selon l’une quelconque des revendications 5 à 7 comprenant une étape (G70) de signalement à ladite entité de contrôle d’au moins un événement détecté par l’entité de vérification parmi :
une nouvelle plateforme de collecte de données impliquée lors de l’accès audit service ;

un niveau d’exposition d’informations d’identification de l’utilisateur supérieur à un seuil donné ;

une nouvelle information d’identification de l’utilisateur détectée par ladite au moins une entité (5) de vérification dans lesdites données analysées ;

une information d’identification de l’utilisateur transmise à une entité tierce qui ne respecte pas des conditions d’utilisation dudit service approuvées par ledit utilisateur.
Procédé de traitement selon l’une quelconque des revendications 5 à 8 comprenant une étape d’envoi au premier dispositif (3) d’un entête (DNS_RESOLVER) comprenant une information de joignabilité (@IP5) de ladite au moins une entité (5) de vérification, ledit entête indiquant audit premier dispositif qu’il doit envoyer ses requêtes de résolution de noms de domaine vers ladite au moins une entité de vérification.
Procédé de configuration d’un service (S) fourni à un premier dispositif (3) par un deuxième dispositif (2) via une connexion dite principale ((C1)) établie entre le premier et le deuxième dispositif, ledit procédé de configuration étant destiné à être mis en œuvre par une entité (6) de coordination et comprenant, sur requête (E50) d’une entité (4) de contrôle, une étape (F30) de configuration du service (S) pour que des données véhiculées sur ladite connexion principale ((C1)) et sur au moins une connexion secondaire ((C2), (C2’)) établie en marge de ladite connexion principale pour la fourniture du service transitent par au moins une entité (5) de vérification sélectionnée par ladite entité (4) de contrôle pour analyser lesdites données.
Procédé de configuration selon la revendication 10 dans lequel l’étape de configuration est précédée d’une étape (F10) de vérification qui consiste à vérifier si ladite entité (4) de contrôle est autorisée à déclencher une analyse desdites données par ladite au moins une entité (5) de vérification.
Procédé de configuration selon la revendication 10 ou 11 comprenant une étape (F20) de transmission à ladite entité (4) de contrôle d’au moins une contrainte dudit service à tenir compte pour sélectionner ladite au moins une entité de vérification.
Procédé de configuration selon l’une quelconque des revendications 10 à 12 dans lequel l’étape de configuration (F30) comprend un déclenchement :
d'une modification d’un mécanisme de résolution de noms de domaine pour inclure une information de joignabilité de ladite au moins une entité de vérification ; ou

d’une activation d’un mécanisme de chaînage de service impliquant ladite au moins une entité de vérification ; ou

d’un mécanisme de routage à la source ; ou

d’une redirection des données vers ladite au moins une entité de vérification.
Procédé de configuration selon la revendication 13 dans lequel le déclenchement d’une modification d’un mécanisme de résolution de noms de domaine comprend une activation au niveau d’une entité (2) impliquée dans la fourniture du service d’un envoi (H50) au premier dispositif d’un entête (DNS_RESOLVER) comprenant ladite information de joignabilité de ladite au moins une entité de vérification, ledit entête indiquant audit premier dispositif qu’il doit envoyer tout ou partie de ses requêtes de résolution de noms de domaine vers ladite au moins une entité de vérification.
Entité (4) de contrôle d’une vérification opérée sur des données véhiculées dans au moins un réseau de communication lors d’un accès par un premier dispositif (3) d’un utilisateur à un service fourni par un deuxième dispositif (2) via une connexion dite principale ((C1)) établie entre le premier et le deuxième dispositif, cette entité de contrôle comprenant :
un module (4B) de déclenchement, configuré pour déclencher auprès d’une entité (6) de coordination, une configuration du service pour que des données véhiculées sur la connexion principale et sur au moins une connexion secondaire ((C2), (C2’)) établie en marge de cette connexion principale pour la fourniture du service transitent par au moins une entité (5) de vérification sélectionnée par l’entité de contrôle pour analyser ces données ; et

un module (4C) de notification, configuré pour notifier l’entité (6) de coordination, si un événement déterminé est détecté dans une identité numérique (IDNUM(U)) de l’utilisateur véhiculée lors de l’accès au service et comprenant des informations d’identification de l’utilisateur obtenues à partir des données analysées par ladite au moins une entité de vérification.
Entité (5) de vérification de données véhiculées sur au moins un réseau de communication lors d’un accès par un premier dispositif (3) d’un utilisateur à un service fourni par un deuxième dispositif (2) via une connexion dite principale ((C1)) établie entre le premier et le deuxième dispositif, au moins une connexion dite secondaire ((C2),(C2’)) étant établie en marge de ladite connexion principale lors de la fourniture dudit service, ladite entité de vérification comprenant :
un module (5A) de réception, configuré pour recevoir des données véhiculées via ladite connexion principale et/ou au moins une dite connexion secondaire ;

un module (5C) de mise à jour, activé si au moins une information d’identification de l’utilisateur est obtenue à partir desdites données et en fonction de ladite au moins une information d’identification obtenue, ledit module étant configuré pour mettre à jour une identité numérique de l’utilisateur véhiculée lors de l’accès audit service ; et

un module (5D) de transmission configuré pour relayer lesdites données reçues à destination du deuxième dispositif.
Entité (6) de coordination apte à configurer un service (S) fourni à un premier dispositif par un deuxième dispositif via une connexion dite principale établie entre le premier et le deuxième dispositif, ladite entité de coordination comprenant un module (6B) de configuration, activé sur requête d’une entité (4) de contrôle et programmé pour configurer ledit service pour que des données véhiculées sur ladite connexion principale et sur au moins une connexion secondaire établie en marge de ladite connexion principale pour la fourniture du service transitent par au moins une entité (5) de vérification sélectionnée par ladite entité de contrôle pour analyser lesdites données.
Système (1) de vérification comprenant au moins une entité (4) de contrôle selon la revendication 15, au moins une entité (5) de vérification selon la revendication 16 et au moins une entité (6) de coordination d’un service (S) selon la revendication 17.