[go: up one dir, main page]

FR3067143A1 - Securisation d'une base de donnees d'authentification par un reseau - Google Patents

Securisation d'une base de donnees d'authentification par un reseau Download PDF

Info

Publication number
FR3067143A1
FR3067143A1 FR1754726A FR1754726A FR3067143A1 FR 3067143 A1 FR3067143 A1 FR 3067143A1 FR 1754726 A FR1754726 A FR 1754726A FR 1754726 A FR1754726 A FR 1754726A FR 3067143 A1 FR3067143 A1 FR 3067143A1
Authority
FR
France
Prior art keywords
user
authentication
ticket
session
terminal
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
FR1754726A
Other languages
English (en)
Inventor
Julien Godier
Alexandre Ferrieux
Matthias Hamel
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
Orange SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orange SA filed Critical Orange SA
Priority to FR1754726A priority Critical patent/FR3067143A1/fr
Publication of FR3067143A1 publication Critical patent/FR3067143A1/fr
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer And Data Communications (AREA)

Abstract

L'invention concerne la communication sécurisée entre une pluralité de terminaux et au moins un serveur, mettant en œuvre, pour chaque terminal qui établit une session de communication avec ledit serveur, via un réseau de communication, le stockage de l'identifiant de ressource réseau du terminal considéré, en association avec l'identifiant utilisateur dudit terminal et une information (ISA) de statut de l'authentification de l'utilisateur correspondant, ladite information étant mise à une première valeur (V1) représentative d'une authentification, selon un premier degré de confiance, de l'utilisateur correspondant. En cas d'incohérence sur l'identifiant d'un utilisateur, toutes les informations de statut stockées en liaison avec un utilisateur passent (S9-S10) de la première valeur à une deuxième valeur (V2) représentative d'une authentification de l'utilisateur, selon un deuxième degré de confiance moins élevé.

Description

® SECURISATION D'UNE BASE DE DONNEES D'AUTHENTIFICATION PAR UN RESEAU.
FR 3 067 143 - A1 (57) L'invention concerne la communication sécurisée entre une pluralité de terminaux et au moins un serveur, mettant en oeuvre, pour chaque terminal qui établit une session de communication avec ledit serveur, via un réseau de communication, le stockage de l'identifiant de ressource réseau du terminal considéré, en association avec l'identifiant utilisateur dudit terminal et une information (ISA) de statut de l'authentification de l'utilisateur correspondant, ladite information étant mise à une première valeur (V1 ) représentative d'une authentification, selon un premier degré de confiance, de l'utilisateur correspondant. En cas d'incohérence sur l'identifiant d'un utilisateur, toutes les informations de statut stockées en liaison avec un utilisateur passent (S9-S10) de la première valeur à une deuxième valeur (V2) représentative d'une authentification de l'utilisateur, selon un deuxième degré de confiance moins élevé.
Figure FR3067143A1_D0001
Figure FR3067143A1_D0002
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 œuvre de communications sécurisées entre une pluralité de terminaux utilisateur et un serveur, tel que par exemple un serveur mettant en œuvre 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 œuvre 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 œuvre 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 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 :
- 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 toute modification susceptible d’impacter le terminal utilisateur ou le réseau de communication. Ce type de ticket intermédiaire est appelé « intérim 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éé 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.
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 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 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 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.
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 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 é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 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 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 utilisateur, dont l’identifiant de communication a été attribué à un autre terminal utilisateur, via le mécanisme des tickets de traçabilité.
Objet 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.
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 œuvre, pour chaque terminal utilisateur qui établit une session de communication avec le serveur, via un réseau de communication, ce qui suit:
- 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,
- 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 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 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 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 de manière fiable, simple et rapide, et avec un minimum d’impacts sur les utilisateurs pour lesquels une association « identifiant de ressource réseauidentifiant 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 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 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 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 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 œuvre 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 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 terminal utilisateur considéré un message qui contient, dans un cookie, ledit identifiant utilisateur.
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 é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 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 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 communication.
Une telle disposition permet de mettre en œuvre 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, 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.
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 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 œuvre d’une authentification du terminal dudit utilisateur.
Il est ainsi possible de s’assurer qu’une communication sécurisée avec le serveur puisse à nouveau être mise en œuvre 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 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 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 œuvre de l’authentification du terminal utilisateur comprend ce qui suit, au niveau du 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 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 (S13a)) à 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.
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 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 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 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 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 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, lorsque chaque terminal utilisateur établit une session de communication avec le 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,
- stocker l’identifiant de ressource réseau, en association avec l’identifiant utilisateur, dans un dispositif de stockage.
Un tel dispositif d’authentification est remarquable en ce que le circuit de traitement met en œuvre, 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 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 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 œuvre des instructions de code de programme pour l’exécution des étapes 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, 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 œuvre des étapes du procédé de communication sécurisée selon l’invention, lorsque le programme est exécuté dans un dispositif d’authentification tel que mentionné ci-dessus.
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 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 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é.
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:
- la figure 1 est une vue schématique et générale d’une architecture dans laquelle est mis en œuvre 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,
- 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 œuvre dans le procédé de la figure 3, selon un mode de réalisation particulier de l’invention,
- la figure 5 représente des détails d’une phase d’authentification mise en œuvre dans le procédé de la figure 3, selon un mode de réalisation particulier de l’invention.
Description détaillée d’un premier mode de réalisation
La figure 1 représente un environnement dans lequel est mis en œuvre 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 cet environnement ne sont pas représentés. De tels éléments sont par exemple des serveurs, des nœuds, 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; T2, ..-,Tj,... Tn (1 <i<N) 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 Télécommunications System »), LTE (abréviation anglaise de « Long Term Evolution »), etc..., à un serveur SERj mettant en œuvre un service ou 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...
Le serveur SERj appartient à un ensemble de serveurs SERi, SER2,..., SERj,...,SERM (1<j<M), 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 l’opérateur de télécommunications auquel sont abonnés les utilisateurs des terminaux ΤΊ, T2,..., Tn, un serveur de fourniture de contenus auquel ont souscrit les utilisateurs des terminaux ΤΊ, 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 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 ΤΊ, T2,..., Tn et l’un des serveurs SERi à SERm, le dispositif 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 » ;
- un ticket de traçabilité de session intermédiaire « intérim update ticket » ;
- un ticket de traçabilité de fin de session « accounting stop ticket ».
Pour chaque ticket « accounting start ticket » correspondant à un utilisateur donné, est enregistrée dans une table de session TS, une association qui définit :
- en entrée, un identifiant IR_T-i de ressource réseau associée au terminal utilisateur T-ι, et en sortie, un identifiant utilisateur IU_Ti associé au terminal T1;
- 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,
... J
- en entrée, un identifiant IR_T, de ressource réseau associée au terminal utilisateur T,, et en sortie, un identifiant utilisateur IU_Tj associé au terminal T,,
- 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.
Pour un terminal utilisateur considéré T,, un identifiant IR_T, est par exemple :
- l’adresse IP (abréviation anglaise de « Internet protocol ») allouée de façon temporaire au terminal T, lors de l’établissement de la session de communication avec le serveur SERj,
- l’adresse du masque de sous-réseau allouée de façon temporaire au terminal T, lors de l’établissement de la session de communication avec le serveur SERj,
- l’adresse SIP (abréviation anglaise de « Session Initiation protocol ») du terminal T,,
- etc...
Pour un terminal utilisateur considéré T,, un identifiant IU_Tj est par exemple :
- l’identifiant d’appel MSISDN (abréviation anglaise de « Mobile Station International Subscriber Directory Number ») correspondant de manière 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 T,,
- le type RAT (abréviation anglaise de « Radio Access Technology») de technologie radio utilisé par le terminal T,, tel que par exemple, UTRAN, GERAN, WLAN, ...,
- le user-agent envoyé par le navigateur du terminal T,,
- 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 terminal T,,
- etc...
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 œuvre une authentification des utilisateurs des terminaux ΤΊ à Tn, dans le cadre de l’établissement d’une communication sécurisée par ces derniers avec un des serveurs SER-ι à 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 pour mettre en œuvre le procédé de communication sécurisée selon l'invention, le circuit de traitement CT contenant un processeur PROC 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 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 terminaux T-ι à TN de la figure 1 et l’un des serveurs SER-ι à SERM de la figure 1, une telle interface étant par exemple de type UMTS, GSM, LTE, IP, etc...,
- une interface de communication COM11 qui est adaptée pour communiquer avec les serveurs SERi à SERm et/ou avec les terminaux ΤΊ à Tn de la figure 1, une telle interface étant par exemple conforme au protocole http (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 identifiants utilisateur correspondants IU-U à IU_TN,
- un dispositif de stockage BD, par exemple une base de données, 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_T-i de ressource réseau associée au terminal utilisateur T-ι, et en sortie, un identifiant utilisateur lU Ti associé au terminal Ti 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 associée au terminal utilisateur T2, et en sortie, un identifiant utilisateur IU_T2 associé au terminal T2et une information ISA de statut d’authentification de l’utilisateur d’un terminal T2, •
... J • en entrée, un identifiant IR_T, de ressource réseau associée au terminal utilisateur T,, et en sortie, un identifiant utilisateur IU_Tj associé au terminal T, et une information ISA de statut d’authentification de l’utilisateur d’un terminal T,, •
... J • 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 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,
- un dispositif AFF d’affectation d’une information ISA de statut d’authentification d’un utilisateur, pour chacune des associations ci-dessous enregistrées dans la table de session TS :
• IR_Tr>IU_Ti, • IR_T2->IU_T2,
... J • IR—Ti->IU_Tj,
... J • 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 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 PROC du circuit de 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 œuvre une authentification implémentée dans le dispositif d’authentification DAUT de la figure 2.
Un terminal utilisateur T,, considéré parmi les N terminaux de la figure 1 requiert une session de communication avec un serveur considéré, par exemple SERj, via le réseau RC. De façon connue en soi, en liaison avec cette session, un premier ticket TTS-h « accounting start ticket » est créé dans le réseau RC, puis une copie de ce ticket est transmise au dispositif d’authentification DAUT.
En S1, le ticket TTSi, est reçu par l’interface COM10 du dispositif d’authentification DAUT, telle qu’illustrée en figure 2. Le ticket TTS-h contient notamment un identifiant IR_Tj de ressource réseau associée au terminal T, et un identifiant utilisateur ΐυ_Τ, associé au terminal T,. Selon un mode de réalisation préféré, l’identifiant IR—T, est l’adresse IP, du terminal T, et l’identifiant IU_Tj et le MSISDN, du terminal T,. Comme mentionné plus haut dans la description, d’autres exemples sont possibles pour le choix de ces identifiants.
En S2, les identifiants IR_Tj et IU_Tj sont extraits du ticket TTSi, par le dispositif d’extraction EXT illustré en figure 2.
En S3, l’association IR_Tj->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 T,. A cet effet, le dispositif AFF extrait de la mémoire tampon MT une première valeur V1 représentative d’une authentification, selon un premier degré de confiance, de l’utilisateur du terminal T,, 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_Tj->IU_Tj.
Un tel processus est itéré pour chacun des terminaux T-ι à TN qui établit une session de communication avec l’un des serveurs SERi à SERm.
Pour un terminal considéré parmi les N terminaux, par exemple le terminal T,, un deuxième ticket TTS21 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 TTS21 est reçu par l’interface COM10 du dispositif d’authentification DAUT. Une incohérence existe entre le deuxième ticket TTS2i et le premier ticket TTS-π, en ce sens que le deuxième ticket TTS21 contient le même identifiant de ressource réseau IR_Tj que le premier ticket TTS-h reçu en S1 et un identifiant utilisateur IU_Tj’ différent de l’identifiant utilisateur IU_T, du premier ticket TTS-n.
En S7, des identifiants IR_T, et IU_Tj’ sont extraits du ticket TTS21 par le dispositif d’extraction EXT.
En S8, le comparateur CMP compare le contenu des deux tickets TTS-n et TTS2i et établit une différence entre l’identifiant utilisateur IU_Tj’ et l’identifiant IU_Tj stocké en S3 en association avec l’identifiant de ressource réseau IR_Tj.
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, relativement à l’ensemble des terminaux Ti à 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>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 table de session TS, en correspondance avec chaque association IR_T-|->IU_T-|, IR_T2->IU_T2,..„ IR_Tn->IU_Tn.
Les incohérences entre un premier ticket TTS-π et un deuxième ticket TTS2i sont par exemple les suivantes :
- un deuxième ticket TTS2, de type « accounting start ticket » a été reçu en S6, tel que contenant l’identifiant de ressource réseau IR_T, et l’identifiant utilisateur IU_Tj’, alors qu’une association IR_Tj->IU_Ti relative à un premier ticket TTS-h de type « accounting start ticket » reçu en S1, a bien été enregistrée en S3, ce qui traduit une perte du ticket de type « accounting stop ticket » associé au premier ticket TTS-n ;
- 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_T, et l’identifiant utilisateur IU_Tj’, alors qu’une association IR_Tj->IU_Ti relative à un premier ticket TTS-π de type « accounting start ticket » reçu en S1, a bien été enregistrée en S3, ce qui traduit une perte soit du ticket de type « accounting stop ticket » associé au premier ticket TTS-π, 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 « intérim update ticket » a été reçu en S6, tel que tel que contenant l’identifiant de ressource réseau IR_T, et l’identifiant utilisateur IU_Tj’, alors qu’une association IR_Tj->IU_Ti relative à un premier ticket TTS-n de type « accounting start ticket » reçu en S1, a bien été enregistrée en S3, ce qui traduit une perte soit du ticket de type « accounting stop ticket >> associé au premier ticket TTS-h, soit du ticket de type « accounting start ticket >> dont les identifiants correspondent à ceux du deuxième ticket TTS21 de type « intérim update ticket >>.
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 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 communication COM 10, une requête d’authentification en provenance d’un des terminaux de ladite pluralité de terminaux T-ι à TN. Il s’agit par exemple du terminal T, 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 T, 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 TS la valeur V1 ou V2 attribuée à l’information ISA de statut d’authentification correspondant à l’association IR_Ti->IU_Tj.
S’il s’agit de la valeur V1, en S111a), le dispositif DAUT envoie au terminal T,, via l’interface de communication COM10, un message de réponse à ladite requête d’authentification, ledit message de réponse contenant, dans un cookie CK, l’identifiant utilisateur IU_Tj correspondant. En fonction du contexte de sécurité requis, le cookie CK est crypté ou non.
S’il s’agit de la valeur V2, en S111b), le dispositif DAUT envoie au terminal T,, 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.
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 T,.
Selon un autre exemple, le message d’erreur est une requête en demande au terminal T, 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 ».
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 ΤΊ à Tn, dont l’information de statut d’authentification ISA a été mise précédemment à la 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 rétablissement d’une nouvelle session de communication avec l’un des serveurs SER-ι à 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 ΤΊ à Tn. Il s’agit par exemple du terminal T, précité. Ladite requête d’authentification contient alors un cookie CK qui contient ou non un identifiant utilisateur du terminal T,.
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 IUT, préalablement stocké dans la table de session TS en association avec l’identifiant réseau IR_Ti.
Si le cookie CK contient bien l’identifiant utilisateur IUT, envoyé précédemment en S111a) (figure 4) au terminal T, 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 T, stockée précédemment en S10 (figure 3), en la première valeur V1 représentative d’une authentification plus sûre de l’utilisateur du terminal T,.
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 IR_Ti->IU_Ti.
Si le cookie CK ne contient pas d’identifiant utilisateur ou bien contient un identifiant utilisateur différent de IU_Tj, 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 T,. En outre, en S204, le dispositif d’authentification DAUT envoie au terminal T, 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.
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 T,.
Selon un autre exemple, le message d’erreur est une requête en demande au terminal T, 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 é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.

Claims (9)

1. Procédé de communication sécurisée entre une pluralité de terminaux utilisateur et au moins un serveur, mettant en œuvre, pour chaque terminal utilisateur qui établit une session de communication avec ledit serveur, via un réseau de communication, ce qui suit:
- réception (S1), 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 (S9-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 l’identifiant utilisateur (IU_Tj) 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.
3. Procédé de communication sécurisée selon la revendication 1 ou la revendication 2, dans lequel, pour un terminal considéré (T,) :
- le premier ticket de traçabilité de session (TTS-h) reçu est un ticket de traçabilité d’établissement de session de communication,
- le deuxième ticket de traçabilité de session (TTS21) reçu, pour lequel 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 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 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 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 mise en oeuvre de l’authentification du terminal utilisateur comprend ce qui suit, au niveau du dispositif d’authentification :
- 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 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) à 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.
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.
7. Dispositif d’authentification (DAUT) adapté pour une communication sécurisée entre une pluralité de terminaux utilisateur et au moins un serveur (SERj), 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 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,
- stocker l’identifiant de ressource réseau, en association avec l’identifiant utilisateur, dans un dispositif de stockage (BD,TS), ledit dispositif d’authentification étant caractérisé en ce que le circuit de traitement met en œuvre, 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) 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 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 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 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.
FR1754726A 2017-05-30 2017-05-30 Securisation d'une base de donnees d'authentification par un reseau Pending FR3067143A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
FR1754726A FR3067143A1 (fr) 2017-05-30 2017-05-30 Securisation d'une base de donnees d'authentification par un reseau

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1754726A FR3067143A1 (fr) 2017-05-30 2017-05-30 Securisation d'une base de donnees d'authentification par un reseau
FR1754726 2017-05-30

Publications (1)

Publication Number Publication Date
FR3067143A1 true FR3067143A1 (fr) 2018-12-07

Family

ID=59746058

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1754726A Pending FR3067143A1 (fr) 2017-05-30 2017-05-30 Securisation d'une base de donnees d'authentification par un reseau

Country Status (1)

Country Link
FR (1) FR3067143A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130047213A1 (en) * 2011-08-15 2013-02-21 Bank Of America Corporation Method And Apparatus For Token-Based Token Termination
EP2887602A1 (fr) * 2013-12-17 2015-06-24 Stonesoft Corporation Atténuation, au niveau de session, d'attaques d'interruption de service

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130047213A1 (en) * 2011-08-15 2013-02-21 Bank Of America Corporation Method And Apparatus For Token-Based Token Termination
EP2887602A1 (fr) * 2013-12-17 2015-06-24 Stonesoft Corporation Atténuation, au niveau de session, d'attaques d'interruption de service

Similar Documents

Publication Publication Date Title
EP2415294B1 (fr) Procédé et dispositif de gestion d&#39;une authentification d&#39;un utilisateur
EP2795878B1 (fr) Procédé de partage d&#39;un contenu multimédia entre utilisateurs
FR3029728A1 (fr) Procede de provisionnement d&#39;un profil de souscripteur pour un module securise
EP3298812B1 (fr) Chargement de profil d&#39;abonnement dans une carte sim embarquée
WO2014199102A1 (fr) Procede d&#39;authentification d&#39;un terminal par une passerelle d&#39;un reseau interne protege par une entite de securisation des acces
EP2795870B1 (fr) Procede d&#39;acces par un terminal de telecommunication a une base de donnees hebergee par une plateforme de services accessible via un reseau de telecommunications
EP3656142B1 (fr) Chargement d&#39;un nouveau profil d&#39;abonnement dans un module embarqué d&#39;identification de souscripteur
WO2010006914A1 (fr) Procédé d&#39;authentification d&#39;un utilisateur d&#39;un service sur terminal mobile
WO2007000552A2 (fr) Procede d&#39;obtention de donnees de configuration pour un terminal par utilisation du protocole dhcp
EP2873211B1 (fr) Procédé d&#39;enregistrement d&#39;au moins une adresse publique dans un réseau ims et application correspondante
EP1983722A2 (fr) Procédé et système de sécurisation d&#39;accès internet de téléphone mobile, téléphone mobile et terminal correspondants
EP2348763A2 (fr) Procédé d&#39;authentification d&#39;un terminal mobile pour accéder à un serveur d&#39;applications
FR3067143A1 (fr) Securisation d&#39;une base de donnees d&#39;authentification par un reseau
FR3057373A1 (fr) Securisation d&#39;une base de donnees d&#39;authentification par un reseau
WO2020025430A1 (fr) Procédé de transmission de données vers deux passerelles distinctes, et dispositif correspondant
WO2011073584A1 (fr) Procede de controle d&#39;acces a un reseau local
FR3072534A1 (fr) Communication securisee entre un terminal et un serveur
FR3028334A1 (fr) Procede d&#39;authentification forte d&#39;un utilisateur d&#39;un equipement consommateur via un equipement d&#39;authentification equipe d&#39;un module de securite
FR3007600A1 (fr) Procede d&#39;authentification d&#39;un utilisateur pour l&#39;acces a un ensemble de services fournis sur un reseau de communication prive
FR3076638A1 (fr) Procede de gestion d&#39;un acces a une page web d&#39;authentification
FR3096479A1 (fr) Procédé de vérification qu’un utilisateur d’un site web est un être humain, et plateforme de vérification associée
FR3112053A1 (fr) Procédé de gestion d’une phase d’appairage entre dispositifs de traitement de données.
FR2943482A1 (fr) Procede et systeme de securisation de demandes applicatives
FR2952262A1 (fr) Autorisation d&#39;etablissement d&#39;appels simultanes
FR2992128A1 (fr) Gestion de l&#39;acces d&#39;un terminal a un reseau de communication par le biais d&#39;une passerelle

Legal Events

Date Code Title Description
PLSC Publication of the preliminary search report

Effective date: 20181207