Brevet FR3067143A1 — publié le 20181207

Sécurisation d'une base de données d'authentification par un réseau Domaine de l'invention Le domaine général de l'invention est celui des télécommunications. L'invention concerne plus particulièrement la mise en oeuvre de communications sécurisées entre une pluralité de terminaux utilisateur et un serveur, tel que par exemple un serveur mettant en oeuvre un service ou une application. Etat de la technique Pour accéder à un tel serveur de façon sécurisée, il est courant de requérir une identification de l'utilisateur. Une telle identification consiste par exemple, pour l'utilisateur, à renseigner un identifiant de connexion comprenant un identifiant d'utilisateur et un mot de passe. L'identifiant de connexion permet à l'administrateur du serveur de gérer les droits d'accès d'un utilisateur associé à cet identifiant pour un service ou une application mis en oeuvre par le serveur. Ce type d'identification oblige l'utilisateur à créer un compte sur un tel serveur et à mémoriser un identifiant de connexion et un mot de passe. Selon un autre exemple, une telle identification consiste à exploiter un identifiant d'un abonnement auprès d'un opérateur, typiquement le MSISDN (abréviation anglaise de « Mobile Station Integrated Services Digital Network Number »). Cet identifiant est le numéro connu du public d'identification de l'utilisateur dans le réseau de son opérateur. C'est cet identifiant, couramment appelé numéro de téléphone, qui doit être composé afin de joindre l'utilisateur ayant souscrit à un abonnement. Lorsqu'un terminal utilisateur est connecté sur le réseau de son propre opérateur, il existe des mécanismes réseau qui permettent à une application ou un service mis en oeuvre dans un serveur détenu par cet opérateur d'obtenir cet identifiant de manière fiable. On parle alors d'authentification implicite de l'utilisateur. De tels mécanismes réseau consistent, pour un terminal utilisateur considéré qui établit une session de 3067143 2 communication sécurisée avec un serveur, à créer à différents instants du déroulement de la session des tickets de traçabilité de la session. De tels tickets sont appelés en anglais « accounting tickets ». Au moins deux tickets de traçabilité de la session sont créés : 5 - un ticket de traçabilité d'établissement de la session, appelé en anglais « accounting start ticket » ; - un ticket de traçabilité de fin de la session, appelé en anglais « accounting stop ticket ». Un ou plusieurs tickets intermédiaires peuvent être créés afin d'indiquer 10 toute modification susceptible d'impacter le terminal utilisateur ou le réseau de communication. Ce type de ticket intermédiaire est appelé « interim update ticket ». Pour une session donnée, un ticket de traçabilité d'établissement de session, un ticket de traçabilité de fin de session et tout ticket intermédiaire créé 15 entre ces deux tickets contiennent chacun : - un identifiant utilisateur associé au terminal utilisateur considéré, typiquement le MSISDN, - un identifiant de ressource réseau attribuée au terminal utilisateur considéré, typiquement une adresse IP. 20 De tels tickets sont transmis dans le réseau pour divers usages. Selon la finalité des traitements de ces tickets, leur mode de transmission peut être acquitté on non. En mode acquitté, le destinataire de chaque ticket se doit de confirmer la bonne réception du ticket. En cas de non confirmation, le ticket sera retransmis jusqu'à réception par le destinataire. En cas d'échecs répétés 25 sur un ticket « accounting start ticket », la connexion de l'utilisateur ne sera pas établie. Ce mode de connexion acquitté étant fortement consommateur de ressources, il est exclusivement réservé à l'usage de la facturation de l'utilisateur. Pour les autres usages, le mode non acquitté est utilisé. Conformément au mode non acquitté, une copie des tickets de traçabilité de 30 session est transmise dans le réseau, sans se préoccuper de leur bonne réception par le destinataire. Ces tickets peuvent ensuite être collectés dans 3067143 3 une base de données du réseau. A cet effet, pour chaque ticket « accounting start ticket » reçu, une association entre l'identifiant de ressource et l'identifiant utilisateur correspondant audit ticket reçu est stockée dans une table de session. 5 Pour un terminal utilisateur considéré, dès qu'un ticket de traçabilité de fin de session a été reçu, il est procédé à l'effacement, dans la table de session, uniquement de l'association stockée en relation avec la session de communication qui concerne le terminal utilisateur considéré. Il a été constaté que des tickets sont régulièrement perdus lors de leur 10 transmission vers la base de données, ce qui entraîne un remplissage incorrect, et du même coup, une désorganisation de la table de session. Par exemple, il se peut que, pour un terminal utilisateur considéré, un ticket de traçabilité de fin de session soit reçu, alors qu'aucun ticket de traçabilité d'établissement de session n'a été stocké au préalable pour le terminal utilisateur considéré. Il peut 15 également arriver, pour un terminal utilisateur considéré, que l'identifiant utilisateur contenu dans un ticket de traçabilité de fin de session ne correspond respectivement pas à l'identifiant utilisateur contenu dans un ticket de traçabilité d'établissement de session relativement au terminal utilisateur considéré. Il peut encore également arriver que l'identifiant utilisateur contenu dans un des tickets 20 de traçabilité associés à un terminal utilisateur considéré soit le même que celui contenu dans un des tickets de traçabilité associés à un autre terminal utilisateur. De telles incohérences ne sont actuellement pas prises en compte dans le réseau, ce qui peut amener un dysfonctionnement dans l'accès d'un terminal 25 utilisateur au serveur. Un tel dysfonctionnement peut s'avérer grandement préjudiciable pour l'opérateur qui propose des services ou des applications sur ce serveur. Par ailleurs, de telles incohérences sont susceptibles d'engendrer des failles dans la sécurité de la communication entre un terminal utilisateur et un serveur, en particulier des risques d'usurpation de l'identité du terminal 30 utilisateur, dont l'identifiant de communication a été attribué à un autre terminal utilisateur, via le mécanisme des tickets de traçabilité. 3067143 4 Obiet et résumé de l'invention Un des buts de l'invention est donc de remédier à des insuffisances/inconvénients de l'état de la technique et/ou d'y apporter des améliorations. 5 A cet effet, un objet de la présente invention concerne un procédé de communication sécurisée entre une pluralité de terminaux utilisateur et au moins un serveur, mettant en oeuvre, pour chaque terminal utilisateur qui établit une session de communication avec le serveur, via un réseau de communication, ce qui suit: 10 - réception, dans un dispositif d'authentification situé dans le réseau de communication, d'un premier ticket de traçabilité de la session contenant: - un identifiant de ressource réseau, - un identifiant utilisateur, 15 - stockage de l'identifiant de ressource réseau, en association avec l'identifiant utilisateur, dans un dispositif de stockage. Un tel procédé est remarquable en ce que pour chaque association stockée, une information de statut de l'authentification de chaque utilisateur correspondant est stockée, l'information étant mise à une première valeur 20 représentative d'une authentification, selon un premier degré de confiance, de chaque utilisateur correspondant, et lorsque pour un terminal considéré, est reçu un deuxième ticket de traçabilité de session pour lequel l'identifiant utilisateur ne correspond pas à celui du premier ticket de traçabilité, toutes les informations de statut stockées passent 25 de la première valeur à une deuxième valeur représentative d'une authentification, selon un deuxième degré de confiance moins élevé que le premier degré de confiance, de chacun des utilisateurs pour lequel une association a été stockée. Une telle disposition permet, pour toute session de communication 30 sécurisée par stockage de tickets de traçabilité de session, entre un terminal utilisateur considéré et un serveur, via un réseau de communication, de gérer 3067143 5 de manière fiable, simple et rapide, et avec un minimum d'impacts sur les utilisateurs pour lesquels une association « identifiant de ressource réseau-identifiant utilisateur » a été préalablement stockée, une perte de transmission de tickets (d'ampleur quelconque) dans ledit réseau, dès lors que cette perte 5 est détectable par une incohérence de contenu entre deux tickets de traçabilité de session relatifs à une même ressource réseau donnée. Selon un exemple de réalisation préférentiel : - le premier degré de confiance représente une confiance absolue dans l'authentification des utilisateurs, dès qu'un premier ticket de traçabilité de 10 session est reçu pour chacun de ces utilisateurs ; - le deuxième degré de confiance représente une confiance faible dans l'authentification des utilisateurs, dès qu'un deuxième ticket de traçabilité de session est reçu pour l'un de ces utilisateurs. De manière avantageuse, cette gestion des pertes ou incohérences de 15 tickets s'accompagne d'une désauthentification de l'ensemble des utilisateurs pour lesquels une association « identifiant de ressource réseau-identifiant utilisateur » a été préalablement stockée. Une telle désauthentification est complètement transparente pour la plupart des utilisateurs, grâce au passage de leur information de statut d'authentification correspondante de la première 20 valeur (confiance absolue) à la deuxième valeur (confiance faible). Il est ainsi possible de s'assurer qu'une prochaine communication sécurisée avec le serveur puisse à nouveau être mise en oeuvre de manière fiable et sûre pour un terminal utilisateur considéré. Selon un mode de réalisation particulier, l'information de statut de 25 l'authentification de l'utilisateur d'un terminal considéré ayant été mise à la première valeur, dans le cas où le dispositif d'authentification reçoit, en provenance du terminal utilisateur considéré, une requête en authentification dudit utilisateur, la requête contenant l'identifiant utilisateur associé au terminal utilisateur considéré, le dispositif d'authentification envoie en réponse au 30 terminal utilisateur considéré un message qui contient, dans un cookie, ledit identifiant utilisateur. 3067143 6 Une telle disposition permet au dispositif d'authentification de tracer simplement l'identification de l'utilisateur du terminal considéré, de façon à éviter toute usurpation frauduleuse de l'identité de cet utilisateur par un autre utilisateur qui chercherait par la suite à poursuivre la session de communication 5 établie entre le terminal utilisateur considéré et ledit serveur. Selon un mode de réalisation particulier, pour un terminal considéré : - le premier ticket de traçabilité de session reçu est un ticket de traçabilité d'établissement de session de communication, - le deuxième ticket de traçabilité de session reçu, pour lequel 10 l'identifiant utilisateur ne correspond pas à celui du premier ticket de traçabilité, est : - soit un ticket de traçabilité de fin de ladite session de communication, - soit un ticket de traçabilité intermédiaire relatif à ladite 15 session de communication, lequel est transmis après la transmission du premier ticket de traçabilité d'établissement de ladite session et avant la transmission du deuxième ticket de traçabilité de fin de ladite session, - soit un autre ticket de traçabilité d'établissement de session 20 de communication. Une telle disposition permet de mettre en oeuvre une désauthentification massive des utilisateurs pour lesquels une association « identifiant de ressource réseau-identifiant utilisateur » a été préalablement stockée, par mise à la deuxième valeur (confiance faible) de leur information de statut respective, 25 une telle désauthentification étant basée sur l'analyse de différents types de tickets de traçabilité de session et concernant des utilisateurs ayant déjà établi une session de communication avec un serveur et pour lesquels un ou plusieurs tickets de traçabilité de session ont déjà été reçus ou bien encore étant en cours d'établissement d'une telle session. 30 Selon un mode de réalisation particulier, le procédé de communication sécurisée comprend en outre, pour un utilisateur dont l'information de statut 3067143 7 d'authentification a été mise à la deuxième valeur et qui souhaite poursuivre la session de communication précédemment en cours ou établir une nouvelle session de communication avec le serveur, la mise en oeuvre d'une authentification du terminal dudit utilisateur. 5 Il est ainsi possible de s'assurer qu'une communication sécurisée avec le serveur puisse à nouveau être mise en oeuvre de manière fiable et sûre pour la pluralité de terminaux utilisateurs considérés. Une authentification de ces terminaux utilisateurs est alors à nouveau nécessaire afin de rétablir les sessions de communication avec le serveur précédemment établies ou 10 précédemment en cours d'établissement, et rompues du fait de cette désauthentification globale des utilisateurs. Une telle désauthentification globale pour l'ensemble des terminaux utilisateurs qui étaient précédemment soit en communication sécurisée avec un serveur, soit en cours d'établissement de communication sécurisée avec ce dernier, permet, moyennant une nouvelle 15 authentification de ces terminaux, d'éviter tout risque d'usurpation d'identité d'un détenteur de l'un ou l'autre de ces terminaux par une personne malveillante. Selon un autre mode de réalisation particulier, la mise en oeuvre de l'authentification du terminal utilisateur comprend ce qui suit, au niveau du 20 dispositif d'authentification : - réception d'une requête d'authentification en provenance du terminal utilisateur, ladite requête d'authentification comprenant un cookie, - comparaison d'un identifiant utilisateur contenu dans le cookie avec l'identifiant utilisateur préalablement stocké en association avec 25 l'identifiant de ressource réseau et l'information de statut d'authentification mise à la deuxième valeur, - en cas d'égalité entre lesdits identifiants utilisateur, l'information de statut de l'authentification de l'utilisateur du terminal est mise (513a)) à la première valeur, 30 - en cas de non égalité entre lesdits identifiants utilisateur ou bien en cas d'absence d'identifiant utilisateur dans le cookie reçu, l'information de 3067143 8 statut de l'authentification de l'utilisateur du terminal reste à la deuxième valeur. Une telle disposition permet, suite à une détection d'une faille de sécurité, et selon les règles d'utilisation propres au serveur : - soit de rétablir, dans un délai court, une communication 5 sécurisée du terminal utilisateur auprès du serveur, moyennant une authentification implicite de l'utilisateur du terminal considéré, lequel n'a pas besoin de saisir à nouveau un identifiant et/ou un mot de passe pour poursuivre la session de communication établie précédemment ou en établir une nouvelle, - soit d'empêcher le rétablissement de la communication sécurisée 10 du terminal utilisateur auprès du serveur, par une détection simple et rapide d'une usurpation frauduleuse de l'identité de l'utilisateur du terminal utilisateur considéré. Selon un autre mode de réalisation particulier, en cas de non égalité entre les identifiants utilisateur ou d'absence d'identifiant utilisateur dans le 15 cookie reçu, le dispositif d'authentification envoie au terminal utilisateur une requête en déconnexion du réseau de communication, puis en reconnexion au réseau. Une telle disposition permet d'éviter au dispositif d'authentification de requérir auprès du terminal utilisateur considéré une nouvelle authentification 20 de ce dernier. Une telle requête de connexion puis déconnexion pourra constituer simplement en une page Web contenant un message du type « Activez puis désactiver le mode avion de votre terminal ». Les différents modes ou caractéristiques de réalisation précités peuvent être ajoutés indépendamment ou en combinaison les uns avec les autres, au 25 procédé de communication sécurisée tel que défini ci-dessus. L'invention concerne également un dispositif d'authentification adapté pour une communication sécurisée entre une pluralité de terminaux utilisateur et au moins un serveur, via un réseau de communication, le dispositif étant situé dans le réseau et comprenant un circuit de traitement qui est agencé pour, 30 lorsque chaque terminal utilisateur établit une session de communication avec le serveur, via ledit réseau : 3067143 9 - recevoir un premier ticket de traçabilité de la session contenant: - un identifiant de ressource réseau, - un identifiant utilisateur, - stocker l'identifiant de ressource réseau, en association avec 5 l'identifiant utilisateur, dans un dispositif de stockage. Un tel dispositif d'authentification est remarquable en ce que le circuit de traitement met en oeuvre, pour chaque association stockée, le stockage d'une information de statut de l'authentification de chaque utilisateur correspondant, ladite information étant mise à une première valeur représentative d'une 10 authentification, selon un premier degré de confiance, de chaque utilisateur correspondant, et lorsque pour un terminal considéré, est reçu un deuxième ticket de traçabilité de session pour lequel l'identifiant utilisateur ne correspond pas à celui du premier ticket de traçabilité, toutes les informations de statut stockées passent de la première valeur à une deuxième valeur représentative 15 d'une authentification, selon un deuxième degré de confiance moins élevé que le premier degré de confiance, de chacun des utilisateurs pour lequel une association a été stockée. L'invention concerne également un programme d'ordinateur pour mettre en oeuvre des instructions de code de programme pour l'exécution des étapes 20 du procédé de communication sécurisée selon l'invention, lorsque le programme est exécuté dans un dispositif d'authentification. Un tel programme peut utiliser n'importe quel langage de programmation et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, 25 ou dans n'importe quelle autre forme souhaitable. L'invention concerne également un support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur, ce programme comportant des instructions adaptées à la mise en oeuvre des étapes du procédé de communication sécurisée selon l'invention, lorsque le 30 programme est exécuté dans un dispositif d'authentification tel que mentionné ci-dessus. 3067143 10 Les supports d'enregistrement peuvent être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, une clé USB ou encore un moyen 5 d'enregistrement magnétique, par exemple un disque dur. D'autre part, le support 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 radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau 10 de type Internet. Alternativement, le support d'enregistrement peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé d'établissement de communication précité. 15 Brève description des dessins D'autres caractéristiques et avantages apparaîtront à la lecture d'un mode de réalisation préféré décrit en référence aux figures dans lesquelles: 20 - la figure 1 est une vue schématique et générale d'une architecture dans laquelle est mis en oeuvre le procédé de communication sécurisée dans un mode de réalisation particulier de l'invention, - la figure 2 représente un dispositif d'authentification dans un mode de réalisation particulier de l'invention, 25 - la figure 3 représente les principales étapes d'un procédé de communication sécurisée dans un mode de réalisation particulier de l'invention, - la figure 4 représente des détails d'une phase d'authentification mise en oeuvre dans le procédé de la figure 3, selon un mode de réalisation particulier de l'invention, 3067143 11 - la figure 5 représente des détails d'une phase d'authentification mise en oeuvre dans le procédé de la figure 3, selon un mode de réalisation particulier de l'invention. 5 Description détaillée d'un premier mode de réalisation La figure 1 représente un environnement dans lequel est mis en oeuvre le procédé de communication sécurisée entre une pluralité de terminaux utilisateur et au moins un serveur, via un réseau de communication. Dans un souci de clarté de la figure 1, certains éléments bien connus de 10 cet environnement ne sont pas représentés. De tels éléments sont par exemple des serveurs, des noeuds, des stations de base, des passerelles ou encore d'autres entités du réseau de télécommunications utilisé dans cet environnement. Sur la figure 1 sont représentés une pluralité de terminaux utilisateur T1, 15 T2, TN (1 accédant, via un réseau de communication RC, tel que par exemple un réseau mobile GSM (abréviation anglaise de « Global System for Mobile communications »), UMTS (abréviation anglaise de « Universal Mobile Telecommunications System »), LTE (abréviation anglaise de « Long Term Evolution »), etc..., à un serveur SERi mettant en oeuvre un service ou 20 une application requise par chacun de ces terminaux. Chaque terminal comprend à cet effet une interface de communication adaptée pour communiquer avec le réseau de communication RC. Il peut s'agir par exemple d'un téléphone portable, d'un smartphone (« téléphone intelligent »), d'une tablette, etc... 25 Le serveur SERi appartient à un ensemble de serveurs SERI, SER2,..., SERi,...,SERNA (1 dont l'accès est sécurisé par un dispositif d'authentification DAUT objet de l'invention. Un tel ensemble de serveurs comprend par exemple un serveur WAP (abréviation anglaise de « Wireless Application Protocol »), un serveur hébergeant les services proposés par 30 l'opérateur de télécommunications auquel sont abonnés les utilisateurs des terminaux T1, T2,..., TN, un serveur de fourniture de contenus auquel ont 3067143 12 souscrit les utilisateurs des terminaux T1, T2,..., TN, etc.... Aucune limitation n'est attachée au nombre de terminaux utilisateur, ni au nombre d'opérateurs de réseau. A titre illustratif, on a choisi un exemple dans lequel à chaque terminal utilisateur est associé un même opérateur de 5 réseau. Toutefois, aucune limitation n'est attachée à cet exemple. Les utilisateurs des N terminaux T1, T2,..., TN peuvent notamment avoir souscrit un abonnement auprès d'un opérateur de réseau distinct. Une fois qu'une session de communication est établie entre chacun des terminaux T1, T2,..., TN et l'un des serveurs SERI à SERm, le dispositif 10 d'authentification DAUT reçoit une copie des tickets de traçabilité de session TTS qui ont été créées dans le réseau RC pour chacun des N terminaux. De tels tickets de traçabilité de session sont par exemple : - un ticket de traçabilité d'établissement de session « accounting start ticket » ; 15 - un ticket de traçabilité de session intermédiaire « interim update ticket » ; - un ticket de traçabilité de fin de session « accounting stop ticket ». Pour chaque ticket « accounting start ticket » correspondant à un 20 utilisateur donné, est enregistrée dans une table de session TS, une association qui définit : - en entrée, un identifiant IR_Ti de ressource réseau associée au terminal utilisateur T1, et en sortie, un identifiant utilisateur IU_Ti associé au terminal T1, 25 - en entrée, un identifiant IR_T2 de ressource réseau associée au terminal utilisateur T2, et en sortie, un identifiant utilisateur IU_T2 associé au terminal T2, - en entrée, un identifiant IR_Ti de ressource réseau associée au 30 terminal utilisateur Ti, et en sortie, un identifiant utilisateur IU_Ti associé au terminal Th 3067143 13 - en entrée, un identifiant IR_TN de ressource réseau associée au terminal utilisateur TN, et en sortie, un identifiant utilisateur IU_TN associé au terminal TN. 5 Pour un terminal utilisateur considéré Tb un identifiant IR_Ti est par exemple : - l'adresse IP (abréviation anglaise de « Internet protocol ») allouée de façon temporaire au terminal Ti lors de l'établissement de la session de communication avec le serveur SERi, 10 - l'adresse du masque de sous-réseau allouée de façon temporaire au terminal Ti lors de l'établissement de la session de communication avec le serveur SERi, - l'adresse SIP (abréviation anglaise de « Session Initiation protocol ») du terminal Tb 15 - etc... Pour un terminal utilisateur considéré Tb un identifiant IU_Ti est par exemple : - l'identifiant d'appel MSISDN (abréviation anglaise de « Mobile Station International Subscriber Directory Number ») correspondant de manière 20 unique à la carte SIM (en anglais « Subscriber Identity Module ») qui est fournie par l'opérateur du réseau de communication RC auprès duquel s'est inscrit l'utilisateur du terminal Tb - le type RAT (abréviation anglaise de « Radio Access Technology ») de technologie radio utilisé par le terminal Tb tel que par 25 exemple, UTRAN, GERAN, WLAN, - le user-agent envoyé par le navigateur du terminal Tb - le support de transmission des données audio/vidéo (en anglais « bearer »), tel que par exemple EDGE, UMTS, WiFi,..., - une valeur représentative de l'activation ou non de l'itinérance du 30 terminal Ti, - etc... 3067143 14 En relation avec la figure 2, on considère maintenant la structure simplifiée du dispositif d'authentification DAUT selon un exemple de réalisation de l'invention. Dans l'exemple représenté, le dispositif DAUT est une plateforme ou bien un serveur adapté pour mettre en oeuvre une authentification des 5 utilisateurs des terminaux T1 à TN, dans le cadre de l'établissement d'une communication sécurisée par ces derniers avec un des serveurs SERI à SERm représentés sur la figure 1. Par exemple, le dispositif d'authentification DAUT comprend des ressources physiques et/ou logicielles, en particulier un circuit de traitement CT 10 pour mettre en oeuvre le procédé de communication sécurisée selon l'invention, le circuit de traitement CT contenant un processeur FROC piloté par un programme d'ordinateur PG. A l'initialisation, les instructions de code du programme d'ordinateur PG sont par exemple chargées dans une mémoire RAM, notée MR, avant d'être 15 exécutées par le circuit de traitement CT. Le dispositif DAUT comprend principalement : - une interface de communication COM10 apte à communiquer avec le réseau RC afin de recevoir, via ce dernier, une copie des tickets de session TTS créés au moment de l'établissement d'une session entre les 20 terminaux T1 à TN de la figure 1 et l'un des serveurs SERI à SERm de la figure 1, une telle interface étant par exemple de type UMTS, GSM, LTE, IF, etc..., - une interface de communication COM11 qui est adaptée pour communiquer avec les serveurs SERI à SERm et/ou avec les terminaux T1 à TN de la figure 1, une telle interface étant par exemple conforme au protocole http 25 (abréviation anglaise de « HyperText Transfer Protocol ») ou https (abréviation anglaise de « HyperText Transfer Protocol Secure »), - un dispositif d'extraction EXT qui est adapté à extraire des tickets de session TTS qui ont été reçus par l'interface de communication COM10, les identifiants de ressources réseau IR_Ti à IR_TN et respectivement les 30 identifiants utilisateur correspondants IU_Ti à IU_TN, - un dispositif de stockage BD, par exemple une base de données, 3067143 15 qui est relié au dispositif d'extraction EXT et qui est adapté pour enregistrer dans une table de session TS, pour chaque ticket « accounting start ticket » correspondant à un utilisateur donné, une association qui définit : - en entrée, un identifiant IR_Ti de ressource réseau 5 associée au terminal utilisateur T1, et en sortie, un identifiant utilisateur IU_Ti associé au terminal T1 et une information ISA de statut d'authentification de l'utilisateur d'un terminal T1, - en entrée, un identifiant IR_T2 de ressource réseau 10 associée au terminal utilisateur T2, et en sortie, un identifiant utilisateur IU_T2 associé au terminal T2 et une information ISA de statut d'authentification de l'utilisateur d'un terminal T2, - 15 - en entrée, un identifiant IR_Ti de ressource réseau associée au terminal utilisateur Ti, et en sortie, un identifiant utilisateur IU_Ti associé au terminal Ti et une information ISA de statut d'authentification de l'utilisateur d'un terminal Th 20 - - en entrée, un identifiant IR_TN de ressource réseau associée au terminal utilisateur TN, et en sortie, un identifiant utilisateur IU_TN associé au terminal TN et une information ISA de statut d'authentification de 25 l'utilisateur d'un terminal TN. Le dispositif d'authentification DAUT comprend en outre : - un dispositif de comparaison CMP adapté pour comparer un identifiant utilisateur contenu dans un ticket reçu courant avec le ou les identifiants utilisateurs stockés dans la table de session TS, 30 - un dispositif AFF d'affectation d'une information ISA de statut d'authentification d'un utilisateur, pour chacune des associations ci-dessous 3067143 16 enregistrées dans la table de session TS : - IR_Ti->IU_Ti, - IR_T2->IU_T2, - 5 - - - IR_TN->IU_TN. - une mémoire tampon MT destinée à stocker au moins deux valeurs V1 et V2 pouvant être prise alternativement par l'information ISA de 10 statut d'authentification d'utilisateur. Les interfaces de communication COM10, COM11, le dispositif d'extraction EXT, le dispositif de stockage BD, le dispositif de comparaison CMP et le dispositif d'affectation AFF d'information de statut d'authentification, la mémoire tampon MT, sont pilotés par le processeur FROC du circuit de 15 traitement CT. En référence à la figure 3, on décrit maintenant le déroulement d'un procédé de communication sécurisée selon l'invention, mettant en oeuvre une authentification implémentée dans le dispositif d'authentification DAUT de la figure 2. 20 Un terminal utilisateur Th considéré parmi les N terminaux de la figure 1 requiert une session de communication avec un serveur considéré, par exemple SERi, via le réseau RC. De façon connue en soi, en liaison avec cette session, un premier ticket TTSi; « accounting start ticket » est créé dans le réseau RC, puis une copie de ce ticket est transmise au dispositif 25 d'authentification DAUT. En Si, le ticket TTSi; est reçu par l'interface COM10 du dispositif d'authentification DAUT, telle qu'illustrée en figure 2. Le ticket TTSi; contient notamment un identifiant IR_T; de ressource réseau associée au terminal T; et un identifiant utilisateur IU_T; associé au terminal Ti. Selon un mode de 30 réalisation préféré, l'identifiant IR_T; est l'adresse IP; du terminal T; et l'identifiant IU_T; et le MSISDN; du terminal Ti. Comme mentionné plus haut 3067143 17 dans la description, d'autres exemples sont possibles pour le choix de ces identifiants. En S2, les identifiants IR_Ti et IU_Ti sont extraits du ticket TTSii par le dispositif d'extraction EXT illustré en figure 2. 5 En S3, l'association IR_Ti->IU_Ti est stockée dans la table de session TS de la base de données BD de la figure 2. En S4, le dispositif AFF de la figure 2 affecte une information ISA de statut d'authentification de l'utilisateur du terminal Ti. A cet effet, le dispositif AFF extrait de la mémoire tampon MT une première valeur V1 représentative 10 d'une authentification, selon un premier degré de confiance, de l'utilisateur du terminal Th et affecte V1 à l'information ISA. En S5, la valeur V1 de l'information ISA est stockée dans la table de session TS, en correspondance avec l'association IR_Ti->IU_Ti. Un tel processus est itéré pour chacun des terminaux T1 à TN qui établit 15 une session de communication avec l'un des serveurs SERI à SERm. Pour un terminal considéré parmi les N terminaux, par exemple le terminal Th un deuxième ticket TTS2; est par la suite créé dans le réseau RC, puis une copie de ce ticket est transmise au dispositif d'authentification DAUT. En S6, le ticket TTS2; est reçu par l'interface COM10 du dispositif 20 d'authentification DAUT. Une incohérence existe entre le deuxième ticket TTS2; et le premier ticket TTSii, en ce sens que le deuxième ticket TTS2; contient le même identifiant de ressource réseau IR_Ti que le premier ticket TTSii reçu en Si et un identifiant utilisateur IU_Ti' différent de l'identifiant utilisateur IU_Ti du premier ticket TTSii. 25 En S7, des identifiants IR_Ti et IU_Ti' sont extraits du ticket TTS2; par le dispositif d'extraction EXT. En S8, le comparateur CMP compare le contenu des deux tickets TTSii et TTS2; et établit une différence entre l'identifiant utilisateur IU_Ti' et l'identifiant IU_Ti stocké en S3 en association avec l'identifiant de ressource réseau IR_Ti. 30 En S9, le dispositif AFF de la figure 2 modifie alors la première valeur V1 de chaque information ISA de statut d'authentification stockée en S5, 3067143 18 relativement à l'ensemble des terminaux T1 à TN, en une deuxième valeur V2 représentative d'une authentification, selon un deuxième degré de confiance moins élevé que le premier degré de confiance précité, de chacun des utilisateurs pour lequel une association IR_T1->IU_T1->ISA(V1), IR_T2->IU_T2- 5 >ISA(V1),..., IR_TN->IU_TN->ISA(V1) a été stockée en S5. A cet effet, le dispositif AFF extrait de la mémoire tampon MT de la figure 2 la deuxième valeur d'authentification V2 et affecte V2 à toutes les informations ISA, en remplacement de V1. En S10, la nouvelle valeur V2 de l'information ISA est stockée dans la 10 table de session TS, en correspondance avec chaque association IR_Ti->IU_Ti, IR_TN->IU_TN. Les incohérences entre un premier ticket TTSii et un deuxième ticket TTS2; sont par exemple les suivantes : - un deuxième ticket TTS2; de type « accounting start ticket » a été 15 reçu en S6, tel que contenant l'identifiant de ressource réseau IR_Ti et l'identifiant utilisateur IU_Ti', alors qu'une association IR_Ti->IU_Ti relative à un premier ticket TTSii de type « accounting start ticket » reçu en Si, a bien été enregistrée en S3, ce qui traduit une perte du ticket de type « accounting stop ticket » associé au premier ticket TTSii ; 20 - un deuxième ticket TTS2; de type « accounting stop ticket » a été reçu en S6, tel que contenant l'identifiant de ressource réseau IR_Ti et l'identifiant utilisateur IU_Ti', alors qu'une association IR_Ti->IU_Ti relative à un premier ticket TTSii de type « accounting start ticket » reçu en Si, a bien été enregistrée en S3, ce qui traduit une perte soit du ticket de type « accounting 25 stop ticket » associé au premier ticket TTSii, soit du ticket de type « accounting start ticket » dont les identifiants correspondent à ceux du deuxième ticket TTS2; de type « accounting stop ticket » ; - un deuxième ticket TTS2; de type « interim update ticket » a été reçu en S6, tel que tel que contenant l'identifiant de ressource réseau IR_Ti et 30 l'identifiant utilisateur IU_Ti', alors qu'une association IR_Ti->IU_Ti relative à un premier ticket TTSii de type « accounting start ticket » reçu en Si, a bien été 3067143 19 enregistrée en S3, ce qui traduit une perte soit du ticket de type « accounting stop ticket » associé au premier ticket TTSii, soit du ticket de type « accounting start ticket » dont les identifiants correspondent à ceux du deuxième ticket TTS2; de type « interim update ticket ». 5 Selon un exemple de réalisation préférentiel : - le premier degré de confiance représente une confiance absolue dans l'authentification des utilisateurs, dès qu'un premier ticket de traçabilité de session est reçu pour chacun de ces utilisateurs ; - le deuxième degré de confiance représente une confiance faible 10 dans l'authentification des utilisateurs, dès qu'un deuxième ticket de traçabilité de session est reçu pour l'un de ces utilisateurs. Conformément à un mode de réalisation représenté sur la figure 4, au cours du procédé de communication sécurisée décrit à la figure 3, le dispositif d'authentification DAUT de la figure 2 reçoit en S100, via l'interface de 15 communication COM10, une requête d'authentification en provenance d'un des terminaux de ladite pluralité de terminaux T1 à TN. Il s'agit par exemple du terminal Ti précité. Selon un exemple, une telle requête est une requête de demande de crédit de communication supplémentaire, dans le cas où l'utilisateur du terminal 20 Ti a épuisé le crédit de communication, par exemple de type « data », associé à son forfait de télécommunications ou bien associé à une carte contenant des unités de communication. Une telle requête est par exemple de type http ou https. En S110, le dispositif d'authentification DAUT lit dans la table de session 25 TS la valeur V1 ou V2 attribuée à l'information ISA de statut d'authentification correspondant à l'association IR_Ti->IU_Ti. S'il s'agit de la valeur V1, en S111a), le dispositif DAUT envoie au terminal Tb via l'interface de communication COM10, un message de réponse à ladite requête d'authentification, ledit message de réponse contenant, dans un 30 cookie CK, l'identifiant utilisateur IU_Ti correspondant. En fonction du contexte de sécurité requis, le cookie CK est crypté ou non. 3067143 20 S'il s'agit de la valeur V2, en S111b), le dispositif DAUT envoie au terminal Tb via l'interface de communication COM10, un message de réponse à ladite requête d'authentification, ledit message de réponse étant du type message d'erreur. 5 Selon un exemple, le message d'erreur est une requête en fourniture d'un identifiant et/ou d'un mot de passe au terminal Ti. Selon un autre exemple, le message d'erreur est une requête en demande au terminal Ti de déconnexion puis de reconnexion au réseau de communication RC de la figure 1. Selon une implémentation préférée, il peut 10 s'agir d'une page contenant un message du type « Veuillez activer puis désactiver le mode avion ». On décrit maintenant en référence à la figure 5 un mode de réalisation d'une phase d'authentiifcation d'un utilisateur d'un des terminaux T1 à TN, dont l'information de statut d'authentification ISA a été mise précédemment à la 15 deuxième valeur V2, comme indiqué en S9, sur la figure 3. Une telle nouvelle authentification est requise par exemple au moment où l'un desdits terminaux requiert auprès du dispositif d'authentification DAUT la poursuite de la session de communication établie précédemment ou bien l'établissement d'une nouvelle session de communication avec l'un des 20 serveurs SERI à SERm. A cet effet, le dispositif d'authentification DAUT de la figure 2 reçoit en S200, via l'interface de communication COM10, une requête d'authentification en provenance d'un des terminaux de ladite pluralité de terminaux T1 à TN. Il s'agit par exemple du terminal Ti précité. Ladite requête d'authentification 25 contient alors un cookie CK qui contient ou non un identifiant utilisateur du terminal Ti. Dans le cas où le cookie CK reçu en S200 contient un identifiant utilisateur, en S201, le dispositif d'authentification DAUT compare l'identifiant utilisateur à l'identifiant utilisateur IU_Ti préalablement stocké dans la table de 30 session TS en association avec l'identifiant réseau IR_Ti. Si le cookie CK contient bien l'identifiant utilisateur IU_Ti envoyé 306 7 143 21 précédemment en S111a) (figure 4) au terminal Ti par le dispositif d'authentification DAUT, le dispositif AFF de la figure 2 modifie en S202 la deuxième valeur V2 de l'information ISA de statut d'authentification de l'utilisateur du terminal Th stockée précédemment en S10 (figure 3), en la 5 première valeur V1 représentative d'une authentification plus sûre de l'utilisateur du terminal Ti. A l'issue de cette opération, la valeur V1 de l'information ISA est stockée en S203 dans la table de session TS, en correspondance avec l'association I R_Ti-> I U_Ti. 10 Si le cookie CK ne contient pas d'identifiant utilisateur ou bien contient un identifiant utilisateur différent de IU_Ti, le dispositif AFF de la figure 2 ne modifie pas la deuxième valeur V2, prise précédemment en S9 par l'information ISA de statut d'authentification de l'utilisateur du terminal Ti. En outre, en S204, le dispositif d'authentification DAUT envoie au terminal Th via l'interface de 15 communication COM10, un message de réponse à ladite requête d'authentification, ledit message de réponse étant du type message d'erreur. Selon un exemple, le message d'erreur est une requête en fourniture d'un identifiant et/ou d'un mot de passe au terminal Ti. Selon un autre exemple, le message d'erreur est une requête en 20 demande au terminal Ti de déconnexion puis de reconnexion au réseau de communication RC de la figure 1. Selon une implémentation préférée, il peut s'agir d'une page contenant un message du type « Veuillez activer puis désactiver le mode avion ». Il va de soi que les modes de réalisation qui ont été décrits ci-dessus ont 25 été donnés à titre purement indicatif et nullement limitatif, et que de nombreuses modifications peuvent être facilement apportées par l'homme de l'art sans pour autant sortir du cadre de l'invention. 30 REVENDICATIONS1. Procédé de communication sécurisée entre une pluralité de terminaux utilisateur et au moins un serveur, mettant en oeuvre, pour chaque terminal utilisateur qui établit une session de communication avec ledit serveur, via un réseau de communication, ce qui suit: - réception (Si), dans un dispositif d'authentification situé dans le réseau de communication, d'un premier ticket de traçabilité de la session contenant: - un identifiant de ressource réseau, - un identifiant utilisateur, - stockage (S3) de l'identifiant de ressource réseau, en association avec l'identifiant utilisateur, dans un dispositif de stockage (BD,TS), ledit procédé étant caractérisé en ce que pour chaque association stockée, une information (ISA) de statut de l'authentification de chaque utilisateur correspondant est stockée (S5), ladite information étant mise à une première valeur (V1) représentative d'une authentification, selon un premier degré de confiance, de chaque utilisateur correspondant, et lorsque pour un terminal considéré, est reçu un deuxième ticket de traçabilité de session pour lequel l'identifiant utilisateur ne correspond pas à celui du premier ticket de traçabilité, toutes les informations de statut stockées passent (59-S10) de la première valeur à une deuxième valeur (V2) représentative d'une authentification, selon un deuxième degré de confiance moins élevé que le premier degré de confiance, de chacun des utilisateurs pour lequel une association a été stockée. 2. Procédé de communication sécurisée selon la revendication 1, dans lequel l'information (ISA) de statut de l'authentification de l'utilisateur d'un terminal considéré ayant été mise à ladite première valeur, dans le cas où le dispositif d'authentification reçoit (S100), en provenance du terminal utilisateur considéré, une requête en authentification dudit utilisateur, ladite requête contenant 3067143 23 l'identifiant utilisateur (IU_Ti) associé au terminal utilisateur considéré, le dispositif d'authentification envoie (S111a)) en réponse au terminal utilisateur considéré un message qui contient, dans un cookie, ledit identifiant utilisateur. 5 3. Procédé de communication sécurisée selon la revendication 1 ou la revendication 2, dans lequel, pour un terminal considéré (Ti) : - le premier ticket de traçabilité de session (TTSii) reçu est un ticket de traçabilité d'établissement de session de communication, - le deuxième ticket de traçabilité de session (TTS2i) reçu, pour lequel 10 l'identifiant utilisateur ne correspond pas à celui du premier ticket de traçabilité, est : - soit un ticket de traçabilité de fin de ladite session de communication, - soit un ticket de traçabilité intermédiaire relatif à ladite session de 15 communication, lequel est transmis après la transmission du premier ticket de traçabilité d'établissement de ladite session et avant la transmission du deuxième ticket de traçabilité de fin de ladite session, - soit un autre ticket de traçabilité d'établissement de session de 20 communication. 4. Procédé de communication sécurisée selon l'une quelconque des revendications 1 à 3, comprenant en outre, pour un utilisateur dont l'information de statut d'authentification a été mise à la deuxième valeur (V2) et qui souhaite 25 poursuivre la session de communication précédemment en cours ou établir une nouvelle session de communication avec ledit serveur, la mise en oeuvre d'une authentification du terminal dudit utilisateur. 5. Procédé de communication sécurisée selon la revendication 4, dans lequel la 30 mise en oeuvre de l'authentification du terminal utilisateur comprend ce qui suit, au niveau du dispositif d'authentification : 3067143 24 - réception (S200) d'une requête d'authentification en provenance du terminal utilisateur, ladite requête d'authentification comprenant un cookie (CK), - comparaison (S201) d'un identifiant utilisateur contenu dans le 5 cookie avec l'identifiant utilisateur préalablement stocké en association avec l'identifiant de ressource réseau et l'information de statut d'authentification mise à la deuxième valeur, - en cas d'égalité entre lesdits identifiants utilisateur, l'information de statut de l'authentification de l'utilisateur du terminal est mise (S202-S203) à 10 la première valeur, - en cas de non égalité entre lesdits identifiants utilisateur ou bien en cas d'absence d'identifiant utilisateur dans le cookie reçu, l'information de statut de l'authentification de l'utilisateur du terminal reste à la deuxième valeur. 15 6. Procédé de communication sécurisée selon la revendication 5, dans lequel, en cas de non égalité entre lesdits identifiants utilisateur ou bien d'absence d'identifiant utilisateur dans le cookie reçu, le dispositif d'authentification envoie (S204) au terminal utilisateur une requête en déconnexion du réseau de communication, puis en reconnexion audit réseau. 20 7. Dispositif d'authentification (DAUT) adapté pour une communication sécurisée entre une pluralité de terminaux utilisateur et au moins un serveur (SERi), via un réseau de communication, ledit dispositif étant situé dans ledit réseau et comprenant un circuit de traitement (CT) qui est agencé pour, lorsque 25 chaque terminal utilisateur établit une session de communication avec ledit serveur, via ledit réseau : - recevoir un premier ticket de traçabilité de la session contenant: - un identifiant de ressource réseau, - un identifiant utilisateur, 30 - stocker l'identifiant de ressource réseau, en association avec l'identifiant utilisateur, dans un dispositif de stockage (BD,TS), 3067143 25 ledit dispositif d'authentification étant caractérisé en ce que le circuit de traitement met en oeuvre, pour chaque association stockée, le stockage d'une information (ISA) de statut de l'authentification de chaque utilisateur correspondant, ladite information étant mise à une première valeur (V1) 5 représentative d'une authentification, selon un premier degré de confiance, de chaque utilisateur correspondant, et lorsque pour un terminal considéré, est reçu un deuxième ticket de traçabilité de session pour lequel l'identifiant utilisateur ne correspond pas à celui du premier ticket de traçabilité, toutes les informations de statut stockées passent de la première valeur à une deuxième 10 valeur (V2) représentative d'une authentification, selon un deuxième degré de confiance moins élevé que le premier degré de confiance, de chacun des utilisateurs pour lequel une association a été stockée. 8. Programme d'ordinateur comportant des instructions de code de programme 15 pour l'exécution des étapes du procédé de communication sécurisée selon l'une quelconque des revendications 1 à 6, lorsque ledit programme est exécuté sur un ordinateur. 9. Support d'enregistrement lisible par un ordinateur sur lequel est enregistré un 20 programme d'ordinateur comprenant des instructions de code de programme pour l'exécution des étapes du procédé de de communication sécurisée selon l'une quelconque des revendications 1 à 6, lorsque ledit programme est exécuté par un ordinateur. 25 30