FR3001595A1 - Procede de detection de fraude dans un reseau ims - Google Patents

Abstract

Ce procédé de détection de fraude peut être mis en œuvre par un serveur HSS dans un réseau IMS. Il comporte : - une étape (E10) de réception d'un message (MSG) en provenance d'une entité I-CSCF ou S-CSCF, ledit message comportant une identité publique (IDPUB) et une identité privée (IDPRIV) ; et - une étape (E15) de vérification de la validité et de la cohérence desdites identités publique (IDPUB) et privée (IDPRIV). le message (MSG) comportant en outre au moins une adresse (ADPUB, ADPRIV) d'un utilisateur dans le réseau IMS. Ce procédé comporte, si ladite validité (E15) n'est pas vérifiée: - une étape (E20) de mémorisation d'une information selon laquelle une fraude a été détectée pour un ensemble comportant ladite identité publique (IDPUB), ladite identité privée (IDPRIV) et ladite au moins une adresse (ADPUB, ADPRIV).

Description

Arrière-plan de l'invention L'invention se situe dans le domaine de la détection de fraude dans un réseau ims.

Les opérateurs téléphoniques ont commencé la migration de leur réseau téléphonique vers des réseaux de voix sur IP (VoIP pour Voice over IP). La convergence des réseaux fixes et mobiles est offerte par le biais des architectures spécifiées par l'organisme de normalisation du 3GPP au travers des solutions IMS. Contrairement aux réseaux commutés téléphoniques, ces réseaux de voix sur IP sont exposés au monde Internet et à l'imagination de ses acteurs malveillants (ou pirates) en terme d'attaques et de tentatives d'usurpation d'identités propres aux réseaux IP. Afin de limiter les conséquences de telles attaques, certains opérateurs mettent en place des mécanismes de verrouillage des comptes utilisateurs lorsqu'un seuil paramétrable par l'opérateur de tentatives infructueuses de connexion au réseau est dépassé. Ce mécanisme n'est pas satisfaisant car il permet aux pirates de verrouiller volontairement certains comptes par tentatives systématiques et successives sur l'ensemble des tranches de numéros attribués à un opérateur, de sorte que ces mécanismes ne sont en pratique pas mis en oeuvre. Au vu du trafic très important sur les réseaux IMS, il est en outre très compliqué de détecter les attaques au moment où elles se produisent de sorte que les mesures de protection sont le plus souvent mises en oeuvre lorsque l'abonné prévient l'opérateur d'une hausse anormale de sa consommation.

Un des objectifs de l'invention est de proposer une solution à ces problèmes. Objet et rés e de l'invention Ainsi et d'une façon générale, l'invention propose une solution centràhsée pour détecter, à la volée, des tentatives de fraude dans un réseeu Iris. et en particulier des tentatives d'usurpation d'identii. Plus précisément: cf uIon un prem'c~. 'n ±itfon concerne un proceck; détection oo fraude mi, en 0.2,,IVP2 Ins. Ce (i - cui une étape de réception d'un message en provenance d'une entité I-CSCF ou SCSCF, ledit message comportant une identité publique, une identité privée et au moins une adresse d'un utilisateur dans le réseau IMS; une étape de vérification de la validité et de la cohérence des identités publique et privée ; et si cette validité n'est pas vérifiée une étape de mémorisation d'une information selon laquelle une fraude a été détectée pour un ensemble comportant cette identité publique, cette identité privée, et cette adresse. Dans un mode particulier de réalisation, le procédé de détection de fraude selon 10 l'invention comporte en outre : une étape de détection, à partir du message, d'une incohérence sur un schéma d'authentification ou d'un échec d'authentification ; et en cas d'une telle détection : une étape de mémorisation d'une information selon laquelle une fraude a été 15 détectée pour un ensemble comportant au moins l'identité publique, l'identité privée, et l'adresse de l'utilisateur. Corrélativement, l'invention concerne un serveur HSS comportant : des moyens de réception d'un message en provenance d'une entité I-CSCF ou S- CSCF dans un réseau IMS, ce message comportant une identité publique, une 20 identité privée et au moins une adresse d'un utilisateur dans le réseau IMS; des moyens de vérification de la validité et de la cohérence desdites identités publique et privée ; et des moyens de mémorisation, si ladite validité n'est pas vérifiée, d'une information selon laquelle une fraude a été détectée pour un ensemble 25 comportant cette identité publique, cette identité privée et cette adresse. Dans un mode particulier de réalisation, le serveur HSS selon l'invention comporte en outre des moyens de détection, à part!r du message, d'une incohérence sur un schéma .d'uthentlfcation, ou d'un ; et en cas d'une tee 30 détection, des moyens de mémorisation d'une information selon laquelle une fraude a été détectée pour un ensemble coi-ipo!-tant Ou reins l'identité publique, l'identité privée, et rutilis,ii or (CU:,.1t.211.1(2 OSDeCt. '1'1VC1 C(..)!1! 35 à I I '11V l^ 1).:P CSCF ou S-CSCF, ce message comportant une identité publique, une identité privée, et au moins une adresse d'un utilisateur dans le réseau IMS. Corrélativement, l'invention concerne une entité I-CSCF ou S-CSCF comportant des moyens d'envoi d'un message à un serveur HSS dans un réseau IMS, ce message comportant une identité publique, une identité privée et au moins une adresse d'un utilisateur dans le réseau IMS. Selon un troisième aspect, l'invention concerne un message pouvant être envoyé par une entité I-CSCF ou S-CSCF à un serveur HSS dans un réseau IMS, ce message comportant une identité publique, une identité privée et au moins une adresse d'un 10 utilisateur dans le réseau IMS. L'invention s'applique en particulier, comme décrit en détail ultérieurement, aux messages UAR, MAR et SAR. Ainsi et d'une façon générale, l'invention propose de distinguer un utilisateur malveillant (ou pirate) de l'utilisateur légitime sur la base de son adresse dans le réseau 15 ims. De façon très avantageuse, le procédé de détection de fraude selon l'invention ne perturbe pas les services fournis au possesseur du compte. Par ailleurs, la détection des fraudes se fait à la volée, de sorte que des mesures de protection peuvent être prises au plus vite, à savoir dès le premier accès frauduleux. 20 Dans un mode préféré de réalisation du procédé de détection de fraude selon l'invention, le message selon l'invention comporte un indicateur binaire représentatif du fait que l'utilisateur accède ou non au réseau IMS à travers une entité NAT de traduction d'adresse. Dans ce cas, l'adresse comprise dans le message est constituée par : 25 - un couple (adresse IP publique, port public) lorsque cet accès ne se fait pas à travers un NAT; ou - un quadruplet (adresse IP publique, port public, adresse IP privée, port privé) lorsque cet accès se fait à travers un NAT. L'inveoltion permet ainsi des 30 ims directement OLl derrière un NAT. Le traitevent ultérieur des atJaquu:- pcH- 'opérateur peut éventuellement prendre ce paramètre en considération. Dans un mode particulier de réalisation, le procédé de détection de fraude selon si le Va!iCrté h cqtr.é vérifi nri.ntctin luscompteL 35 Dans un mode particulier de réalisation, le procédé de détection de fraude selon l'invention comporte en outre, lorsqu'une incohérence sur un schéma d'authentification ou d'un échec d'authentification a été détectée, une étape d'incrémentation d'un deuxième compteur de faute associé à l'ensemble comportant l'identité publique, l'identité privée et l'adresse. Dans un mode particulier de réalisation, le procédé de détection de fraude selon l'invention comporte une étape de mise à jour d'un compteur de faute global associé à l'identité publique, ce compteur de faute global totalisant la somme de tous les premiers et deuxièmes compteurs associés à un ensemble comportant cette identité publique.

Chacun de ces compteurs peut être associé à un ou plusieurs seuils prédéterminés, des actions spécifiques de gestion de fraude étant mises en oeuvre lorsque des critères prédéterminés basés sur ces compteurs et seuils sont vérifiés. Par exemple, lorsque l'un de ces compteurs dépasse un premier seuil prédéterminé, le serveur HSS selon l'invention envoie à l'entité I-CSCF un message comportant l'identifiant d'une entité S-CSCF de collecte de fraude. Cet aspect particulier de l'invention permet de rediriger les requêtes d'enregistrement émises par des pirates vers un « pot de miel » pour analyser, comprendre et répertorier les procédures utilisées par les pirates pour utiliser frauduleusement les comptes des utilisateurs.

On rappelle que les « pots de miel » sont des entités volontairement vulnérables destinées à piéger les pirates. Malheureusement, les solutions de « pot de miel » utilisées à ce jour par certains opérateurs sont peu efficaces car la probabilité qu'un pirate se fasse piéger par de telles solutions est très faible. En effet, dans l'état actuel de la technique, un pirate attaque un tel pot de miel uniquement par hasard, par exemple lorsqu'il utilise une méthode de scan IP pour déterminer les adresses de ses cibles de façon systématique ou aléatoire. Ce mode de réalisation particulier de l'invention dans lequel le trafic du fraudeur est reacherniné vers un pot de miel, à son insu, améliore grandement ies techniques cohr;UeS d L:e jour.

Dans ui deuxième exemple, non exclusif du premier exemple décrit ci-dessus, lorsque l'un de ces compteurs dépasse un de' xieme seuil prédéte-mine, ie serveur HSS selon l'invention envoie l'entité I-CSCF un code creri eur. - un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis en oeuvre dans un serveur HSS, ce programme comportant des instructions adaptées à la mise en oeuvre des étapes du procédé de détection de fraude tel que mentionné ci-dessus ; - un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis en oeuvre dans une entité I-CSCF ou S-CSCF, ce programme comportant des instructions adaptées à la mise en oeuvre des étapes du procédé d'envoi de message tel que mentionné ci-dessus. L'un ou l'autre de ces programmes peut utiliser n'importe quel langage de 10 programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable. L'invention vise aussi un support d'informations lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus. 15 Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy disc) ou un disque dur. 20 D'autre part, le support d'informations 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'informations peut être un circuit intégré dans lequel 25 le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question. Brève description des dessins 30 D'autres caractéristiques et avantages de la présente invention ressortiront de la 35 S CSCF nn -ractère Umrttif. Sur les figures : FIS HO . fiL r-cFrE J un descripion faite ci-dessous, en exemple de re.lu.uitior, dépourvu représer (Sonfor flu' rocks prirUculier .éférence aux dessins annexés qui en illustrent un Cii.1?1' - la figure 3 représente un message conforme à l'invention ; - la figure 4 représente sous forme d'organigramme les principales étapes d'un procédé de détection de fraude conforme à un mode particulier de réalisation de l'invention ; et - les figures 5 et 6 représentent sous forme d'organigramme les principales étapes de deux procédés d'envoi de message conformes à deux modes particuliers de réalisation de l'invention.

Description détaillée de l'invention La figure 1 représente un serveur HSS, une entité I-CSCF et une entité S-CSCF conformes à l'invention dans un réseau IMS. Elle illustre également les différents messages échangés sur les interfaces SIP et Diameter lors de l'enregistrement d'un abonné UE (traits pleins) ou d'un pirate UE2 (traits tiretés) dans ce réseau. Seuls les messages nécessaires à la compréhension de l'invention sont représentés. Dans ce mode de réalisation, le réseau IMS comporte un gestionnaire de fraude FM incorporant une entité S-CSCF2 utilisée en pot de miel comme décrit ultérieurement. Nous supposerons dans cet exemple que l'abonné UE accède au réseau IMS derrière un équipement de traduction d'adresse NAT, et que le pirate UE2 accède directement au réseau IMS, c'est-à-dire sans l'intermédiaire d'un équipement NAT. Les figures 2A, 2B et 2C représentent de façon schématique l'architecture matérielle du serveur HSS, de l'entité I-CSCF et de l'entité S-CSCF. Dans le mode de réalisation décrit ici, chacun de ces équipements a l'architecture matérielle d'un ordinateur. Le serveur HSS comporte un processeur 11, une mémoire vive 12, une mémoire morte de type ROM 13 et des moyens de communication 14. La mémoire morte 13 comport,c un prodiM111'2. d'ordinateur Pl conforme à c:,:écut:on fun procé.fli, -,eLectium Lc)ii cri no I ÏVL'fltIOfl et dont les étapes El0 à E60 5c! -ont décrite uilii_efieurement en réference à la figure 4, L'entité I-CSCF compo processeur 21, une mémoire vive 22, une mémoire typoPOr-ii 22 et des communication 24. IPOrtit.2 hO35 dont les principales étapes F10 à F40 seront décrites ultérieurement en référence à la figure 5. L'entité S-CSCF comporte un processeur 31, une mémoire vive 32, une mémoire morte de type ROM 33 et des moyens de communication 34.

La mémoire morte 33 comporte un programme d'ordinateur P3 conforme à l'invention pour l'exécution d'un procédé d'envoi de message conforme à l'invention et dont les principales étapes G10 à G50 seront décrites ultérieurement en référence à la figure 6. En référence à la figure 1, on se place dans le contexte dans lequel l'entité I- CSCF reçoit une requête d'enregistrement REGISTER en provenance de l'abonné UE ou du pirate UE2, au cours d'une étape F10. Cette requête comporte, comme de façon connue, une identité publique IDPUB et une identité privée IDPRIV de l'abonné UE ou du pirate UE2. Comme de façon connue, sur réception de cette requête d'enregistrement, le serveur I-CSCF interroge le serveur HSS pour savoir si les identités publique IDPUB et privée IDPRIV sont connues de ce dernier et autorisées à accéder au réseau IMS. A cet effet, le serveur I-CSCF envoie un message UAR au serveur HSS au cours d'une étape F20. Le serveur HSS reçoit cette requête UAR au cours d'une étape E10. Comme dans l'art antérieur, cette requête UAR comporte les identités publique IDPUB et privée IDPRIV comprises dans la requête d'enregistrement REGISTER. Conformément à l'invention, cette requête UAR comporte en outre l'adresse publique ADPUB de l'équipement émetteur de la requête d'enregistrement REGISTER, éventuellement complétée par l'adresse privée ADPRIV de cet équipement, lorsque celui-ci accède derrière un équipement de traduction d'adresses NAT.

Dans le mode de réalisation décrit ici, une adresse publique ADPUB est constituée par un couple (adresse IP ©IPPUB, port OPORTPUB) ; de même une adresse privée ADPRIV est constituée par un couple (adresse IP 'fDIPRIV, port C_à)PORTPRIV). Le messace UAP ont donc confornic u messagc ISG représenté à Fa figure 3. Or ' NAT dont la o.- ut reprébative du tait que l'utilisateur accédé ou non au FéuedLi iris via une entité NAT de traduction d'adresses. Lorsque c'est le cas, l'adresse privée ADPRIV est pi- ieJite dans le message MSG. Le -,.el-vetir HSS vérifie, flL. CA et la un:rccL e IDPUB et - Si c'est le cas, le serveur HSS renvoie un message d'acquittement UAA à l'entité I-CSCF au cours d'une étape E16, ce message d'acquittement étant reçu de l'entité ICSCF au cours d'une étape F30. L'entité I-CSCF sélectionne ensuite, comme de façon connue, une entité S-CSCF au cours d'une étape F40 et lui fait suivre la requête d'enregistrement reçue à l'étape F10. L'entité S-CSCF reçoit cette requête d'enregistrement REGISTER au cours d'une étape G10. Au cours d'une étape G20, le HSS envoie une requête MAR au serveur HSS pour obtenir les informations d'authentification. Comme dans l'art antérieur, cette requête MAR comporte les identités publique IDPUB et privée IDPRIV comprises dans la requête d'enregistrement REGISTER. Conformément à l'invention, cette requête MAR comporte en outre l'adresse publique ADPUB de l'équipement émetteur de la requête d'enregistrement REGISTER, éventuellement complétée par l'adresse privée ADPRIV de cet équipement, lorsque celui- ci accède derrière un équipement de traduction d'adresses NAT. Cette requête d'enregistrement MAR est conforme au message MSG de la figure 3. Cette requête d'enregistrement MAR est reçue par le serveur HSS au cours d'une autre instance de l'étape E10 déjà décrite. Ainsi, sur réception de cette requête, l'entité HSS met en oeuvre l'étape E15 pour vérifier la validité et la cohérence des identités publique IDPUB et privée IDPRIV. Si c'est le cas, le serveur HSS renvoie un message d'acquittement MAA à l'entité S-CSCF au cours d'une étape E31, ce message d'acquittement étant reçu de l'entité S- CSCF au cours d'une étape G30. Si l'authentification de l'abonné UE est correcte, l'entité S-CSCF envoie, au cours d'une étape G40, une requête SAR au HSS pour télécharger le profil de service de l'abonné. Comme clans l'art aiitriej, cette equte SAR dentites publique IDPUB et pfn,,ei.-2 IDPRIV comprises di-Jw-; la requeu: d',2nregistrernent REGISTER. Conformément à l'invention, cette rcqJête SAR comporte en outre l'adresse publique ADPUB de l'équipement émettbur de In requête d'enrepist-ement REGISTER, cm eUein;:nt corr;1,Jee privec ADPRIV dot cepemeil ric2reu ecu, tré liuure 3.

Cette requête d'enregistrement SAR est reçue par le serveur HSS au cours d'une autre instance de l'étape E10 déjà décrite. Ainsi, sur réception de cette requête, l'entité HSS met en oeuvre l'étape E15 pour vérifier la validité et la cohérence des identités publique IDPUB et privée IDPRIV.

Si c'est le cas, le serveur HSS renvoie un message d'acquittement SAA à l'entité S-CSCF au cours d'une nouvelle instance de l'étape E31, ce message d'acquittement étant reçu de l'entité S-CSCF au cours d'une étape G50. Autrement dit, les entités I-CSCF et S-CSCF conformes à l'invention se distinguent de celles connues de l'art antérieur en ce qu'elles envoient, dans chacun des échanges sur les interfaces Diameter, des informations ADPUB permettant d'identifier l'abonné UE ou le pirate UE2 par son adresse IP de transport et son port (adresse IP et le port UDP ou TCP sur lequel l'enregistrement est reçu), éventuellement complétées par des informations privées ADPRIV lorsque l'accès se fait derrière un NAT. Ces adresses ADPUB et ADPRIV sont accessibles par les entités I-CSCF et S- CSCF par exemple dans l'en-tête SIP Via, dans l'entête Contact ou dans tout autre élément d'information connu de l'homme du métier. Dans le mode de réalisation décrit ici, ces informations d'adresses sont fournies au serveur HSS dans un nouvel attribut Diameter AVP (Attribute Value Pair) dédié à cet effet ou dans l'AVP Frame-IP Address existant avec extension dans le cas de l'accès derrière un NAT. Nous allons maintenant expliquer, en référence à la figure 4, le traitement des messages reçus sur l'interface Diameter par le serveur HSS, en cas de non validité ou de non cohérence des identités publique IDPUB ou privée IDPRIV (résultat du test E15 négatif) et en cas d'une incohérence sur un schéma d'authentification ou d'un échec d'authentification (résultat du test E30 négatif). Pour l'un ou l'autre de ces problèmes, on mémorise (étape E20 ou E32) une information selon laquelle une fraude a été détectée pour le triplet ENS {identité publique IDPUB, identité privée IDPP.IV, adresse pubiique ADPUB}, ou loi que l'accès se fait derrière un quadiuplet ENS e adresse publique ADPUB, adresse privée ADPRIV Dans le mode particulier de réalisation décrit ici, on utilise trois compteurs à savoir F' - U ' CO 1 11 p'..0 11 1 1 " -un deuxième compteur CPT_PB_AUTH, associé à l'ensemble ENS triplet/quadruplet, incrémenté au cours d'une étape E35 lorsque le HSS détecte une incohérence dans un schéma d'authentification ou un échec d'authentification ; et - un compteur de faute global CPT_GLOB associé à l'identité publique IDPUB, mis à jour au cours d'une étape E37 et totalisant la somme desdits premier et deuxième compteurs CPT_PB_IDS, CPT_PB_AUTH associés à tous les triplets/quadruplets ENS comportant cette identité publique IDPUB. Le premier compteur CPT_PB_IDS est notamment incrémenté (étape E22) dès lors que les erreurs suivantes seront constatées par le HSS sur réception des commandes Diameter UAR, MAR et SAR - DIAMETER_ERROR IDENTITIES_DONT_MATCH, - DIAMETER_AUTHORIZATION_REJEL I ED. Le deuxième compteur CPT_PB_AUTH est notamment incrémenté (étape E35) dès lors que les erreurs ou informations suivantes sont constatées ou reçues par le HSS dans les commandes Diameter MAR et SAR : - DIAMETER_ERROR_AUTH_SCHEME_NOT_SUPPORTED, ou - AVP Server-Assignement type valorisé à Authentication_failure, ou encore - AVP Server-Assignement type valorisé à Authentication_timeout. Le compteur de faute global CPT_GLOB, mis à jour à l'étape E37, permet de détecter une attaque par variations d'adresses, dans le cas où le pirate ne changerait qu'un élément de l'adresse, par exemple le port, puisque dans ce cas, le compteur global augmenterait très rapidement. Dans le mode de réalisation décrit ici, on définit deux seuils pour chacun des compteurs et plus précisément - un premier seuil Si et un deuxième seuil S2 pour le premier compteur CPT_PB_IDS ; - un premier seuil et un deuxième seuil S2' pour le deuxième compteur CPT PB LJTH ; et e CPT G LC Ces compteurs peuvent èt:.c u-lises pour mettre en oeuvre des actions spécifiques lorsqu'une fraude est detectéé. 1 sont préférentiellement réinitialisés ou détruit iiiicune fmucl,-2n LleCt, E40 positif), le serveur HSS envoie, au cours d'une étape E42, un message MSG_FAULT vers le gestionnaire de fraude FM, ce message comportant l'adresse publique et éventuellement l'adresse privée du pirate UE2. Une alarme ALM peut être remontée vers l'opérateur afin que celui-ci puisse analyser la stratégie du pirate.

Dans ce mode de réalisation, lorsque cette condition est réalisée, le serveur HSS envoie à l'entité I-CSCF, au cours d'une étape E45, un message UAA comportant l'identifiant S-CSCF2 d'une entité S-CSCF de collecte de fraude. Les requêtes ultérieures d'enregistrement émises par le pirate UE2 présentant les caractéristiques d'une attaque seront ainsi redirigées vers l'entité S-CSCF2 de collecte de fraude selon le mécanisme du pot de miel connu de l'homme du métier. La fourniture de ce nom de S-CSCF ne provoque pas les procédures de libération du S-CSCF assigné à l'utilisateur UE qui continue de disposer de son service alors même qu'une attaque est cours sur son compte client. Dans le mode de réalisation décrit ici, dès lors qu'un compteur CPT_PB_IDS, CPT_PB_AUTH, CPT_GLOB est supérieur à son deuxième seuil S2, S2', S2", le mécanisme de redirection vers le pot de miel S-CSCF2 décrit ci-dessus est interrompu de sorte à protéger le pot de miel lui-même. En revanche, le serveur HSS envoie à l'entité I-CSCF, au cours d'une étape E55, un message comportant un code d'erreur ERR, par exemple le code de retour Diameter DIAME I ER-ERROR-DROP. Sur réception de ce message, le serveur I-CSCF peut décider de ne plus répondre aux messages du pirate ; le pirate, n'obtenant ainsi plus d'informations en réponse à ses attaques pourrait ainsi y mettre fin. Les seuils 52, S2', 52" seront choisis suffisamment grands pour que le pot de miel S-CSCF2 puisse récupérer suffisamment d'informations pertinentes sur les fraudes. D'autres compteurs (par exemple un par type de commande Diameter) et/ou d'autres utilisations de ces compteurs peuvent être utilisés sans sortir du cadre de l'invention. De retour à la figure 2A - Les moyens 14 de communication du ser .our iTSS constituent des moyens de 1SC', not 1.1:Arz C:::Céd.,:rfli"1"ii provc'nance des entite.s I.-CSCF ou S-CSCF confo-rinés à .'n',.érition ; et - Le processeur 11 du serveur HSS est apte, en exécutant les instructions du programme Pl rnemoré dans la mémoire 13 à vérifier la validité et de la cohérence IDPUB et privée IDPRIV, et à détecter un probline clnulocift:uon or réqeau ; -I: r ne moins une identité publique IDPUB, une identité privée IDPRIV et au moins une adresse ADPUB, ADPRIV, - De même, en référence aux figures 2B et 2C, les moyens de communication 24 et 34 des entités I-CSCF et S-CSCF constituent des moyens d'envoi d'un message MSG à un serveur HSS conforme à l'invention. Dans la description faite précédemment, l'information selon laquelle une fraude a été détectée est mémorisée pour un ensemble triplet ou quadruplet comportant l'identité publique IDPUB, l'identité privée et l'adresse ADPUB, éventuellement ADPRIV lorsque l'accès se fait derrière un NAT.

En variante, on mémorise cette information, non pas pour une identité publique IDPUB mais pour un ensemble d'enregistrement implicite IRS (initiales des mots anglais « Impliat Registration ID Set») comportant cette identité publique.

Claims (14)

1. REVENDICATIONS1. Procédé de détection de fraude mis en oeuvre par un serveur HSS dans un réseau IMS comportant : une étape (E10) de réception d'un message (MSG) en provenance d'une entité ICSCF ou S-CSCF, ledit message comportant une identité publique (IDPUB) et une identité privée (IDPRIV) ; et une étape (E15) de vérification de la validité et de la cohérence desdites identités publique (IDPUB) et privée (IDPRIV) ; ledit procédé étant caractérisé en ce que ledit message (MSG) comporte en outre au moins une adresse (ADPUB, ADPRIV) d'un utilisateur dans le réseau IMS et en ce qu'il comporte, si ladite validité (E15) n'est pas vérifiée: une étape (E20) de mémorisation d'une information selon laquelle une fraude a été détectée pour un ensemble comportant ladite identité publique (IDPUB), ladite identité privée (IDPRIV) et ladite au moins une adresse (ADPUB, ADPRIV).
2. 2. Procédé de détection de fraude selon la revendication 1, caractérisé en ce qu'il comporte en outre : une étape (E30) de détection, à partir dudit message (MSG), d'une incohérence sur un schéma d'authentification ou d'un échec d'authentification ; et en cas d'une telle détection (E30), une étape (E32) de mémorisation d'une information selon laquelle une fraude a été détectée pour un ensemble comportant au moins ladite identité publique (IDPUB), ladite identité privée (IDPRIV) et ladite au moins une adresse (ADPUB, ADPRIV).
3. 3. Procele de détection de fraude selon la revendication 1 ou 2, caractérise en ce que aqc c.op,-,po,Tte ;Id.c:ateut lecit utilisal_e--1 accède ou non au réseau 1113 u travers une entité NAT de traduction l'adresse, et en ce que ladite au moins une adresse (ADPUB, ADPRD,I) est constituée par : - un couple (adresse IP publique, port public) (g)IPPI.29, ORTPUB) lorsque ledit accès ne se fait pas a travers uneu .1'"TPLIP r
4. 4. Procédé de détection de fraude selon la revendication 1 ou 2, caractérisé en ce qu'il comporte, si ladite validité n'est pas vérifiée (E15), une étape (E22) d'incrémentation d'un premier compteur de faute (CPT_PB_IDS) associé audit ensemble.
5. 5. Procédé de détection de fraude selon la revendication 2, caractérisé en ce qu'il comporte en outre, lorsqu'une incohérence sur un schéma d'authentification ou d'un échec d'authentification a été détectée, une étape (E35) d'incrémentation d'un deuxième compteur de faute (CPT_PB_AUTH) associé audit ensemble.
6. 6. Procédé de détection de fraude selon les revendications 4 et 5 caractérisé en ce qu'il comporte une étape (E37) de mise à jour d'un compteur de faute global (CPT_GLOB) associé à ladite identité publique (ID PUB), ledit compteur de faute global (CPT_GLOB) totalisant la somme de tous lesdits premiers (CPT_PB_IDS) et deuxièmes (CPT_PB_AUTH) compteurs associés à un ensemble comportant ladite identité publique (ID_PUB).
7. 7. Procédé de détection de fraude selon l'une quelconque des revendications 4 à 6 caractérisé en ce qu'il comporte lorsque ledit premier compteur (CPT_PB_IDS) ou lorsque ledit second compteur (CPT_PB_AUTH) ou lorsque ledit compteur global (CPT_GLOB) dépasse un premier seuil prédéterminé (Si, Sr, Si"), une étape (E42) d'envoi d'un message (MSG_FAULT) vers un gestionnaire de fraude (FM), ledit message comportant au moins ladite adresse publique (ADPUB).
8. 8. Procédé de détection de fraude selon les revendications 4 ou 5 et 6 caractérisé en ce qu'il comporte lorsque ledit premier compteur (CPT_PB_IDS) ou lorsque ledit second compteur (CPT_PB_AUTH) ou lorsque ledit compteur global (CPT_GLOB) dépasse un premier seuil prédéterminé (Si, Sr, Si"), une étape (E45) d'envoi à ladite entité ICSCF, d'un message comportant l'identifiant (5-CSCF2) d'une entité S-CSCF de collecte de fidude
9. 9. Procédé de détection de fraude revendications 4 ou 5 et 6 caractérisé en ce qu'il comporte lorsque ledit preiniu- -ompteur (CPT_PB_IDS) ou lorsque lcdft second ( PB AUT GI.OH) (E55..., d'envoi il r1, cs
10. 10. Procédé d'envoi d'un message à un serveur HSS dans un réseau IMS, ledit procédé étant mis en oeuvre par une entité I-CSCF ou S-CSCF, ledit message comportant une identité publique (IDPUB) et une identité privée (IDPRIV), ledit procédé étant caractérisé en ce que ledit message comporte en outre au moins une adresse (ADPUB, ADPRIV) d'un utilisateur dans le réseau IMS.
11. 11. Serveur HSS comportant : des moyens (14) de réception d'un message (MSG) en provenance d'une entité ICSCF ou S-CSCF dans un réseau IMS, ledit message comportant une identité 10 publique (IDPUB) et une identité privée (IDPRIV) ; et - des moyens (11) de vérification de la validité et de la cohérence desdites identités publique (IDPUB) et privée (IDPRIV) ; ledit serveur HSS étant caractérisé en ce que ledit message (MSG) comporte en outre au moins une adresse (ADPUB, ADPRIV) d'un utilisateur dans le réseau IMS et en ce qu'il 15 comporte : - des moyens (12) de mémorisation, si ladite validité n'est pas vérifiée, d'une information selon laquelle une fraude a été détectée pour un ensemble comportant au moins ladite identité publique (IDPUB), ladite identité privée (IDPRIV) et ladite au moins une adresse (ADPUB, ADPRIV). 20
12. 12. Entité I-CSCF ou S-CSCF caractérisée en ce qu'elle comporte des moyens (24, 34) d'envoi d'un message (MSG) à un serveur HSS dans un réseau IMS, ledit message comportant une identité publique (IDPUB), une identité privée (IDPRIV) et au moins une adresse (ADPUB, ADPRIV) d'un utilisateur dans le réseau IMS.
13. 13. Programme d'ordinateur (P1) comportant des instructions pour l'exécution des étapes du procédé d'envoi de détection de fraude selon l'une quelconque des revendiutions 1 à 9 lorsque ledit programme est exécuté par un serveur HSS dans un leseau 11S.
14. 14. Propranime d'ordinateur (P2, P3) comportant des instructions pour l'exécution de et.ape, du pro Lmlo (fenvoi cie ni,,,ssage selon la revendication 10 lorsdue ledft proor t-iecu pdr une ent'1,:;: CSCI: dans 25 30(IDPUB), une identité privée (IDPRIV) et au moins une adresse (ADPUB, ADPRIV) d'un utilisateur dans le réseau IMS.