WO2014114894A1 - Procédé de détection de fraude dans un réseau ims - Google Patents

Procédé de détection de fraude dans un réseau ims Download PDF

Info

Publication number
WO2014114894A1
WO2014114894A1 PCT/FR2014/050142 FR2014050142W WO2014114894A1 WO 2014114894 A1 WO2014114894 A1 WO 2014114894A1 FR 2014050142 W FR2014050142 W FR 2014050142W WO 2014114894 A1 WO2014114894 A1 WO 2014114894A1
Authority
WO
WIPO (PCT)
Prior art keywords
message
address
public
cpt
fraud
Prior art date
Application number
PCT/FR2014/050142
Other languages
English (en)
Inventor
Jean-Claude Le Rouzic
José DOREE
Original Assignee
Orange
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 filed Critical Orange
Priority to US14/763,461 priority Critical patent/US20150358336A1/en
Priority to EP14704851.6A priority patent/EP2949100A1/fr
Publication of WO2014114894A1 publication Critical patent/WO2014114894A1/fr

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/12—Applying verification of the received information
    • H04L63/126—Applying verification of the received information the source of the received data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1016—IP multimedia subsystem [IMS]
    • 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/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1408—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
    • 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/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/102—Gateways
    • H04L65/1033—Signalling gateways
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1073—Registration or de-registration
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2101/00—Indexing scheme associated with group H04L61/00
    • H04L2101/30—Types of network names
    • H04L2101/395—Internet protocol multimedia private identity [IMPI]; Internet protocol multimedia public identity [IMPU]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4588—Network directories; Name-to-address mapping containing mobile subscriber information, e.g. home subscriber server [HSS]

Definitions

  • the invention lies in the field of detecting fraud in a network.
  • VoIP networks are exposed to the Internet and to the imagination of its malicious actors (or hackers) in terms of attacks and attempts to impersonate IP networks.
  • One of the objectives of the invention is to propose a solution to these problems.
  • the invention proposes a centralized solution for detecting, on the fly, attempts of fraud in an IMS network, and in particular attempts at identity theft.
  • the invention relates to a fraud detection method implemented by an HSS server in an IMS network.
  • This process comprises: a step of receiving a message from an I-CSCF or S-CSCF entity, said message mentioning a public identity, a private identity and at least one address of a user in the IMS network,
  • the fraud detection method according to the invention furthermore comprises:
  • the invention relates to an HSS server comprising:
  • the HSS server according to the invention furthermore comprises:
  • the invention applies in particular, as described in detail later, to the UAR, MAR and SAR messages.
  • the invention proposes to distinguish a malicious user (or hacker) from the legitimate user on the basis of his address in the IMS network.
  • the fraud detection method according to the invention does not interfere with the services provided to the account owner.
  • the detection of fraud is done on the fly, so that protective measures can be taken as quickly as possible, namely from the first fraudulent access.
  • the message according to the invention comprises a binary indicator representative of whether or not the user accesses the IMS network through a NAT entity of address translation. .
  • the address included in the message consists of:
  • the invention thus makes it possible to detect hacker attacks accessing the IMS network directly or behind a NAT.
  • the subsequent processing of the attacks by the operator can possibly take this parameter into consideration.
  • the fraud detection method comprises, if the validity and the consistency of the aforementioned public and private identities is not verified, a step of incrementing a first associated fault counter to the set including public identity, private identity and address.
  • the fraud detection method according to the invention furthermore comprises, when an inconsistency on an authentication scheme or an authentication failure has been detected, a step of incrementing a second fault counter associated with the set comprising the public identity, the private identity and the address.
  • the fraud detection method comprises a step of updating a global fault counter associated with the public identity, this global fault counter totaling the sum of all the first and second counters associated with a set comprising this public identity.
  • Each of these counters can be associated with one or more predetermined thresholds, specific fraud management actions being implemented when predetermined criteria based on these counters and thresholds are verified.
  • the HSS server when one of these counters exceeds a first predetermined threshold, sends to the I-CSCF entity a message with the identifier of an S-CSCF fraud collection entity.
  • This particular aspect of the invention makes it possible to redirect the registration requests sent by hackers to a "honeymoon" to analyze, understand and list the procedures used by the hackers to fraudulently use the accounts of the users.
  • honeypot solutions used to date by some operators are not very effective because the probability that a hacker is trapped by such solutions is very low. Indeed, in the current state of the art, a hacker attacks such honeypot only by chance, for example when using an IP scan method to determine the addresses of its targets systematically or randomly.
  • the HSS server when one of these counters exceeds a second predetermined threshold, the HSS server according to the invention sends to the I-CSCF entity an error code.
  • the various steps of the fraud detection method mentioned above are determined by computer program instructions.
  • the invention also relates to a computer program on an information carrier, this program being capable of being implemented in a server
  • this program comprising instructions adapted to the implementation of the steps of the fraud detection method as mentioned above.
  • Either of these programs can use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form , or in any other desirable form.
  • the invention also relates to an information carrier, irremovable, or partially or completely removable, readable by a computer, and comprising instructions of a computer program as mentioned above.
  • the information carrier may be any entity or device capable of storing the program.
  • the medium may comprise storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a magnetic recording medium such as a hard disk, or a USB key ( "USB flash drive”.
  • the information medium may be a transmissible medium such as an electrical or optical signal, which may be conveyed via an electrical or optical cable, by radio or by other means.
  • the program according to the invention can be downloaded in particular on an Internet type network.
  • the information carrier may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the method in question.
  • FIG. 1 represents an HSS server, an I-CSCF entity and an S_CSCF entity conforming to a particular embodiment of the invention in an IMS network;
  • FIGS. 2A, 2B and 2C respectively represent the hardware architecture of the HSS server, the I-CSCF entity and the S_CSCF entity of FIG. 1;
  • FIG. 3 represents a message according to the invention
  • FIG. 4 represents, in flowchart form, the main steps of a fraud detection method according to a particular embodiment of the invention.
  • FIG. 1 represents an HSS server, an I-CSCF entity and an S-CSCF entity according to the invention in an IMS network. It also illustrates the different messages exchanged on the SIP and Diameter interfaces when registering a UE subscriber (solid lines) or a UE2 hacker (dashed lines) in this network. Only the messages necessary for the understanding of the invention are represented.
  • the IMS network includes an FM fraud manager incorporating an S-CSCF2 entity used in a honeycomb as described later.
  • the UE subscriber accesses the IMS network behind a NAT address translation equipment, and that the UE2 hacker directly accesses the IMS network, that is to say without the intermediary of a device. NAT.
  • FIGS. 2A, 2B and 2C schematically represent the hardware architecture of the HSS server, the I-CSCF entity and the S-CSCF entity.
  • each of these devices has the hardware architecture of a computer.
  • the server HSS comprises a processor 11, a random access memory 12, a read-only memory ROM 13 and communication means 14.
  • the read-only memory 13 comprises a computer program PI according to the invention for executing a fraud detection method according to the invention and whose main steps E10 to E60 will be described later with reference to FIG. .
  • the entity I-CSCF comprises a processor 21, a random access memory 22, a ROM-type read only memory 23 and communication means 24.
  • the read-only memory 23 comprises a computer program P2 according to the invention for the execution of a message sending method according to the invention and whose main steps F10 to F40 will be described later with reference to FIG. 5.
  • the entity S-CSCF comprises a processor 31, a random access memory 32, a ROM ROM 33 and communication means 34.
  • the read-only memory 33 comprises a computer program P3 according to the invention for the execution of a message sending method according to the invention and whose main steps G10 to G50 will be described later with reference to FIG. 6.
  • This request comprises, as in known manner, a public identity IDPUB and a private identity IDPRIV of the UE subscriber or the hacker UE2.
  • the I-CSCF server upon receipt of this registration request, queries the HSS server to know whether the public identities IDPUB and private IDPRIV are known to the latter and authorized to access the IMS network. For this purpose, the I-CSCF server sends a UAR message to the HSS server during a step F20. The HSS server receives this request UAR during a step E10. As in the prior art, this request UAR comprises the identities public IDPUB and private IDPRIV included in the registration request REGISTER.
  • this request UAR furthermore comprises the public address ADPUB of the equipment issuing the registration request REGISTER, possibly supplemented by the private address ADPRIV of this equipment, when it accesses behind a device NAT address translation.
  • a public address ADPUB is constituted by a pair (IP address @IPPUB, port @PORTPUB); likewise a private address ADPRIV is constituted by a couple (IP address @IPRIV, port @PORTPRIV).
  • the UAR message is therefore in accordance with the MSG message represented in FIG.
  • this MSG message includes a NAT binary indicator whose value is representative of whether or not the user accesses the IMS network via a NAT entity for address translation.
  • the private address ADPRIV is present in the message MSG.
  • the HSS server verifies, during a step E15, the validity and the coherence of the public identities IDPUB and private IDPRIV.
  • the HSS server returns a UAA acknowledgment message to the entity
  • the entity I-CSCF selects, as in known manner, an entity S-CSCF during a step F40 and makes it follow the registration request received at the step
  • the S-CSCF entity receives this REGISTER registration request during a step G10.
  • the HSS sends a MAR request to the HSS server to obtain the authentication information.
  • this MAR request comprises the public identities IDPUB and private IDPRIV included in the registration request REGISTER.
  • this request MAR furthermore includes the public address ADPUB of the equipment issuing the REGISTER registration request, possibly supplemented by the private address ADPRIV of this equipment, when it accesses behind a device NAT address translation.
  • This MAR registration request conforms to the MSG message of the figure
  • This MAR registration request is received by the HSS server during another instance of the already described step E10.
  • the HSS entity implements step E15 to check the validity and consistency of IDPUB and IDPRIV private identities.
  • the HSS server returns a MAA acknowledgment message to the S-CSCF entity during a step E31, this acknowledgment message being received from the S-CSCF entity during a step G30.
  • the entity S-CSCF sends, during a step G40, a SAR request to the HSS to download the service profile of the subscriber.
  • this SAR request includes the IDPUB and private identities IDPRIV included in the REGISTER registration request.
  • this SAR request furthermore includes the public address ADPUB of the equipment issuing the REGISTER registration request, possibly supplemented by the private address ADPRIV of this equipment, when it accesses behind a device NAT address translation.
  • This SAR request is therefore in accordance with the MSG message of FIG.
  • This SAR registration request is received by the HSS server during another instance of the already described step E10.
  • the HSS entity implements step E15 to check the validity and consistency of IDPUB public and IDPRIV private identities.
  • the HSS server returns a SAA acknowledgment message to the entity
  • step E31 this acknowledgment message being received from the S-CSCF entity during a step G50.
  • the I-CSCF and S-CSCF entities according to the invention are distinguished from those known from the prior art in that they send, in each of the exchanges on the Diameter interfaces, ADPUB information enabling the identification the UE subscriber or the UE2 hacker by its transport IP address and its port (IP address and the UDP or TCP port on which the registration is received), possibly supplemented by ADPRIV private information when the access is done behind a NAT.
  • ADPUB information enabling the identification the UE subscriber or the UE2 hacker by its transport IP address and its port (IP address and the UDP or TCP port on which the registration is received), possibly supplemented by ADPRIV private information when the access is done behind a NAT.
  • ADPUB and ADPRIV addresses are accessible by the I-CSCF and S-CSCF entities, for example in the Via SIP header, in the Contact header or in any other piece of information known to those skilled in the art.
  • this address information is provided to the HSS server in a new Attribute Value Pair attribute dedicated to that purpose or in existing TAVP Frame-iP Address with extension in the case of access. behind a NAT.
  • step E20 or E32 it is memorized (step E20 or E32) information that a fraud has been detected for the triplet ENS ⁇ IDPUB public identity, IDPRIV private identity, ADPUB public address ⁇ , or when access is behind a NAT for the ENS quadruplet (IDPUB public identity, IDPRIV private identity, ADPUB public address, ADPRIV private address).
  • a first counter CPT_PB_IDS associated with the set ENS triplet / quadruplet, incremented during a step E22 when the HSS detects a problem of validity and coherence of the identities public IDPUB or private IDPRIV (result of the negative test E15);
  • a second counter CPT_PB_AUTH associated with the set ENS triplet / quadruplet, incremented during a step E35 when the HSS detects an inconsistency in an authentication scheme or an authentication failure
  • CPT_PB_IDS CPT_PB_AUTH associated with all ENS triples / quads with this IDPUB public identity.
  • the first counter CPT_PB_IDS is notably incremented (step E22) as soon as the following errors will be noticed by the HSS on receipt of the commands
  • the second counter CPT_PB_AUTH is notably incremented (step E35) as soon as the following errors or information are observed or received by the HSS in the Diameter MAR and SAR commands:
  • the global fault counter CPT_GLOB updated in step E37, makes it possible to detect an attack by address variations, in the case where the hacker does not change that an element of the address, for example the port, since in this case, the global counter would increase very quickly.
  • two thresholds are defined for each of the counters and more precisely:
  • These counters can be used to implement specific actions when a fraud is detected. They are preferentially reset or destroyed if no fraud is detected for a predetermined duration.
  • the server HSS sends, during a step E42, a message MSG_FAULT to the fraud manager FM, this message including the public address and possibly the private address of the hacker UE2.
  • An ALM alarm can be raised to the operator so that the operator can analyze the hacker's strategy.
  • the server HSS when this condition is fulfilled, sends to the entity I-CSCF, during a step E45, a message UAA comprising the identifier S-CSCF2 of an entity S-CSCF of fraud collection.
  • This S-CSCF name does not cause the release procedures of the S-CSCF assigned to the UE user who continues to have his service even though an attack is being made on his client account.
  • the server HSS sends to the entity I-CSCF, during a step E55, a message comprising an error code ERR, for example the return code Diameter DIAMETER-ERROR-DROP.
  • ERR error code
  • the I-CSCF server may decide to stop responding to hacker messages; the hacker, thus obtaining more information in response to his attacks could thus put an end to it.
  • the thresholds S2, S2 ', S2 will be chosen large enough that the honeycomb S-CSCF2 can recover sufficient relevant information on fraud.
  • the communication means 14 of the HSS server are means for receiving the MSG messages, including UAR, MAR and SAR described above, from the I-CSCF or S-CSCF entities according to the invention.
  • the processor 11 of the server HSS is able, by executing the instructions of the program PI stored in the memory 13 to check the validity and the coherence of said identities public IDPUB and private IDPRIV, and to detect an authentication problem on the IMS network ;
  • the memory 12 of the HSS server is a means for storing information according to which fraud has been detected for a set comprising at least one public IDPUB identity, a private IDPRIV identity and at least one address ADPUB, ADPRIV.
  • the communication means 24 and 34 of the I-CSCF and S-CSCF entities constitute means for sending a MSG message to an HSS server according to the invention.
  • the information that a fraud has been detected is stored for a triplet or quadruplet set comprising the public IDPUB identity, the private identity and the ADPUB address, possibly ADPRIV when the access is behind a NAT.
  • this information is memorized, not for a public identity IDPUB but for an implicit registration set 1RS (initials of the English words "Implicit Registration ID Set”) comprising this public identity.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Multimedia (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

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 mentionnant 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 message (MSG) mentionnant 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

PROCEDE DE DETECTION DE FRAUDE DANS UN RESEAU IMS
Arrière-plan de rinvention 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 œuvre.
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 œuvre 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ésumé de l'invention
Ainsi et d'une façon générale, l'invention propose une solution centralisée pour détecter, à la volée, des tentatives de fraude dans un réseau IMS, et en particulier des tentatives d'usurpation d'identité.
Plus précisément, l'invention concerne un procédé de détection de fraude mis en œuvre par un serveur HSS dans un réseau IMS. Ce procédé comporte : une étape de réception d'un message en provenance d'une entité I-CSCF ou S- CSCF, ledit message mentionnant 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 l'invention comporte en outre :
une étape de détection, à partir dudit 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é détectée pour un ensemble comportant au moins ladite identité publique, ladite identité privée, et ladite au moins une adresse.
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 mentionnant une identité publique, une 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 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, à 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, des moyens de mémorisation d'une information selon laquelle une fraude a été détectée pour un ensemble comportant au moins ladite identité publique, ladite identité privée et ladite au moins une adresse. 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 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.
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 :
- 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'invention permet ainsi de détecter des attaques de pirates accédant au réseau IMS directement ou derrière un NAT. Le traitement ultérieur des attaques par l'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 l'invention comporte, si la validité et la cohérence des identités publique et privée précitées n'est pas vérifiée, une étape d'incrémentation d'un premier 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 en outre, lorsqu'une incohérence sur un schéma d'authentification ou un échec d'authentification a été détecté, 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 œuvre 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 réacheminé vers un pot de miel, à son insu, améliore grandement les techniques connues à ce jour.
Dans un deuxième exemple, non exclusif du premier exemple décrit ci-dessus, lorsque l'un de ces compteurs dépasse un deuxième seuil prédéterminé, le serveur HSS selon l'invention envoie à l'entité I-CSCF un code d'erreur.
Dans un mode particulier de réalisation, les différentes étapes du procédé de détection de fraude mentionné ci-dessus sont déterminées par des instructions de programmes d'ordinateurs.
En conséquence, l'invention vise aussi un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis en œuvre dans un serveur
HSS, ce programme comportant des instructions adaptées à la mise en œuvre des étapes du procédé de détection de fraude tel que mentionné ci-dessus.
L'un ou l'autre de ces programmes peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable.
L'invention vise aussi un support d'informations, inamovible, ou partiellement ou totalement amovible, lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus.
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 un moyen d'enregistrement magnétique tel qu'un disque dur, ou encore une clé USB (« USB flash drive » en anglais). 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 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
D'autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif. Sur les figures :
- la figure 1 représente un serveur HSS, une entité I-CSCF et une entité S_CSCF conformes à un mode particulier de réalisation de l'invention dans un réseau IMS ;
- les figures 2A, 2B et 2C représentent respectivement l'architecture matérielle du serveur HSS, de l'entité I-CSCF et de l'entité S_CSCF de la figure 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 comporte un programme d'ordinateur PI conforme à l'invention pour l'exécution d'un procédé de détection de fraude conforme à l'invention et dont les principales étapes E10 à E60 seront décrites ultérieurement en référence à la figure 4.
L'entité I-CSCF comporte un processeur 21, une mémoire vive 22, une mémoire morte de type ROM 23 et des moyens de communication 24.
La mémoire morte 23 comporte un programme d'ordinateur P2 conforme à l'invention pour l'exécution d'un procédé d'envoi de message conforme à l'invention et 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 @PORTPUB) ; de même une adresse privée ADPRIV est constituée par un couple (adresse IP @IPRIV, port @PORTPRIV).
Le message UAR est donc conforme au message MSG représenté à la figure 3.
On notera que ce message MSG comporte un indicateur binaire NAT dont la valeur est représentative du fait que l'utilisateur accède ou non au réseau IMS via une entité NAT de traduction d'adresses. Lorsque c'est le cas, l'adresse privée ADPRIV est présente dans le message MSG.
Le serveur HSS vérifie, au cours d'une étape E15, 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 UAA à l'entité
I-CSCF au cours d'une étape E16, ce message d'acquittement étant reçu de l'entité I-
CSCF 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 œuvre 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 dans l'art antérieur, cette requête SAR 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 SAR 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 SAR est donc conforme au message MSG de la figure 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 œuvre 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 TAVP 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 IDPRIV, adresse publique ADPUB}, ou lorsque l'accès se fait derrière un NAT pour le quadruplet ENS {identité publique IDPUB, identité privée IDPRIV, adresse publique ADPUB, adresse privée ADPRIV}.
Dans le mode particulier de réalisation décrit ici, on utilise trois compteurs, à savoir :
-un premier compteur CPT_PB_IDS, associé à l'ensemble ENS triplet/quadruplet, incrémenté au cours d'une étape E22 lorsque le HSS détecte un problème de validité et de cohérence des identités publique IDPUB ou privée IDPRIV (résultat du test E15 négatif) ;
-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_REJECTED.
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 SI' et un deuxième seuil S2' pour le deuxième compteur CPT_PB_AUTH ; et
un premier seuil SI" et un deuxième seuil S2" pour le compteur global CPT_GLOB.
Ces compteurs peuvent être utilisés pour mettre en œuvre des actions spécifiques lorsqu'une fraude est détectée. Ils sont préférentiellement réinitialisés ou détruits si aucune fraude n'est détectée pendant une durée prédéterminée.
Dans le mode de réalisation décrit ici lorsqu'au moins un de ces compteurs CPT_PB_IDS, CPT_PB_AUTH, CPT_GLOB est supérieur à son premier seuil SI, SI', SI", ces trois compteurs étant inférieurs à leur deuxième seuil S2, S2', S2" (résultat du test 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 DIAMETER-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 S2, S2', S2" 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 serveur HSS constituent des moyens de réception des messages MSG, notamment UAR, MAR et SAR décrits précédemment, en provenance des entités I-CSCF ou S-CSCF conformes à l'invention ; et
- Le processeur 11 du serveur HSS est apte, en exécutant les instructions du programme PI mémorisé dans la mémoire 13 à vérifier la validité et de la cohérence desdites identités publique IDPUB et privée IDPRIV, et à détecter un problème d'authentification sur le réseau IMS ;
- La mémoire 12 du serveur HSS constitue des moyens de de mémorisation d'une information selon laquelle une fraude a été détectée pour un ensemble comportant au 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 1RS (initiales des mots anglais « Implicit Registration ID Set») comportant cette identité publique.

Claims

REVENDICATIONS
1. Procédé de détection de fraude mis en œuvre 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é I-
CSCF ou S-CSCF, ledit message mentionnant 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) mentionne 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. 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. Procédé de détection de fraude selon la revendication 1 ou 2, caractérisé en ce que ledit message comporte un indicateur binaire représentatif du fait que ledit utilisateur accède ou non au réseau IMS à travers une entité NAT de traduction d'adresse, et en ce que ladite au moins une adresse (ADPUB, ADPRIV) est constituée par :
- un couple (adresse IP publique, port public) (@IPPUB, @PORTPUB) lorsque ledit accès ne se fait pas à travers un NAT, ou
- un quadruplet (adresse IP publique, port public, adresse IP privée, port privé) (@IPPUB, @PORTPUB, @IPPRIV, @PORTPRIV) lorsque ledit accès se fait à travers un NAT.
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. 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 un échec d'authentification a été détecté, une étape (E35) d'incrémentation d'un deuxième compteur de faute (CPT_PB_AUTH) associé audit ensemble.
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. 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, SI', 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. 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, SI', SI"), une étape (E45) d'envoi à ladite entité I-CSCF, d'un message comportant l'identifiant (S-CSCF2) d'une entité S-CSCF de collecte de fraude.
9. 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 deuxième seuil prédéterminé (S2, S2', S2"), une étape (E55) d'envoi à ladite entité I-CSCF, d'un message comportant un code d'erreur (ERR).
10. Serveur HSS comportant :
des moyens (14) de réception d'un message (MSG) en provenance d'une entité I-
CSCF ou S-CSCF dans un réseau IMS, ledit message mentionnant une identité 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, lorsque ledit message (MSG) mentionne également au moins une adresse (ADPUB, ADPRIV) d'un utilisateur dans le réseau IMS, il comporte en outre :
- 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).
11. Serveur HSS selon la revendication 10, caractérisé en ce qu'il comporte en outre :
des moyens 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, des moyens 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).
12. Programme d'ordinateur (PI) comportant des instructions pour l'exécution des étapes du procédé de détection de fraude selon l'une quelconque des revendications
1 à 9 lorsque ledit programme est exécuté par un serveur HSS dans un réseau IMS.
13. Support d'informations, inamovible, ou partiellement ou totalement amovible, lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur pour l'exécution des étapes du procédé de détection de fraude selon l'une quelconque des revendications 1 à 9.
PCT/FR2014/050142 2013-01-28 2014-01-24 Procédé de détection de fraude dans un réseau ims WO2014114894A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US14/763,461 US20150358336A1 (en) 2013-01-28 2014-01-24 Method for detecting fraud in an ims network
EP14704851.6A EP2949100A1 (fr) 2013-01-28 2014-01-24 Procédé de détection de fraude dans un réseau ims

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1350689A FR3001595A1 (fr) 2013-01-28 2013-01-28 Procede de detection de fraude dans un reseau ims
FR1350689 2013-01-28

Publications (1)

Publication Number Publication Date
WO2014114894A1 true WO2014114894A1 (fr) 2014-07-31

Family

ID=48613752

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2014/050142 WO2014114894A1 (fr) 2013-01-28 2014-01-24 Procédé de détection de fraude dans un réseau ims

Country Status (4)

Country Link
US (1) US20150358336A1 (fr)
EP (1) EP2949100A1 (fr)
FR (1) FR3001595A1 (fr)
WO (1) WO2014114894A1 (fr)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3270598A3 (fr) * 2016-07-15 2018-03-21 Intraway R&D S.A. Système et procédé pour la fourniture d'informations
US11271967B2 (en) 2017-05-02 2022-03-08 International Business Machines Corporation Methods and systems for cyber-hacking detection
EP3442191B1 (fr) * 2017-08-07 2020-09-23 Nokia Solutions and Networks Oy Prevention de la mystification d'identite dans un reseau de communication

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8213901B2 (en) * 2004-04-28 2012-07-03 Nokia Corporation Subscriber identities

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7818580B2 (en) * 2005-08-09 2010-10-19 International Business Machines Corporation Control of port based authentication protocols and process to support transfer of connection information
US20080219241A1 (en) * 2007-03-09 2008-09-11 Nokia Corporation Subscriber access authorization
US8442526B1 (en) * 2007-09-24 2013-05-14 Sprint Spectrum L.P. Method and system for registering a mobile node via a registration proxy
EP2215805B1 (fr) * 2007-11-30 2011-10-12 Telefonaktiebolaget LM Ericsson (publ) Stockage de données de réseau
US9036541B2 (en) * 2009-02-17 2015-05-19 T-Mobile Usa, Inc. Location-based IMS server selection
US9013992B2 (en) * 2009-09-08 2015-04-21 Wichorus, Inc. Method and apparatus for network address translation
US8533348B2 (en) * 2011-10-18 2013-09-10 At&T Intellectual Property I, L.P. Failover communication services

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8213901B2 (en) * 2004-04-28 2012-07-03 Nokia Corporation Subscriber identities

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
"3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; 3G security; Access security for IP-based services (Release 12)", 3GPP STANDARD; 3GPP TS 33.203, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. SA WG3, no. V12.1.0, 19 September 2012 (2012-09-19), pages 1 - 115, XP050649220 *
ERICSSON: "Validation of public user identity in registration", 3GPP DRAFT; S3-010328-VALIDATION OF PUBLICID, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. CN WG2, no. Dresden; 20010706, 16 July 2001 (2001-07-16), XP050478022 *

Also Published As

Publication number Publication date
FR3001595A1 (fr) 2014-08-01
US20150358336A1 (en) 2015-12-10
EP2949100A1 (fr) 2015-12-02

Similar Documents

Publication Publication Date Title
Kührer et al. Going wild: Large-scale classification of open DNS resolvers
EP2884716B1 (fr) Mécanisme d'authentificaiton par jeton
US10326730B2 (en) Verification of server name in a proxy device for connection requests made using domain names
US9641545B2 (en) Methods, systems, and computer program products for detecting communication anomalies in a network based on overlap between sets of users communicating with entities in the network
WO2006035140A1 (fr) Procede, dispositif et programme de detection d'usurpation de point d'acces.
US9756071B1 (en) DNS denial of service attack protection
WO2010112741A1 (fr) Procédé et dispositif de gestion d'une authentification d'un utilisateur
WO2014114894A1 (fr) Procédé de détection de fraude dans un réseau ims
WO2011083226A1 (fr) Procédé de détection d'un détournement de ressources informatiques
EP2920942B1 (fr) Selection de periodes de rafraichissement dans un reseau ip
EP2550776B1 (fr) Procede de gestion des enregistrements dans un reseau ims et serveur s-cscf mettant en oeuvre ce procede
EP3053321A1 (fr) Technique de restauration d'un service dans un réseau
FR2888696A1 (fr) Detection de double attachement entre un reseau filaire et au moins un reseau sans-fil
EP4066461B1 (fr) Procédé de coordination de la mitigation d'une attaque informatique, dispositif et système associés
FR3105486A1 (fr) Procédé de détection d’un comportement malveillant dans un réseau de communication, dispositif, équipement d’accès audit réseau, procédé de détection d’une attaque distribuée dans ledit réseau, dispositif, équipement nœud et programmes d’ordinateur correspondants
WO2015097363A1 (fr) Procédé de ralentissement d'une communication dans un réseau
EP2365686B1 (fr) Procédé et dispositif de traitement d'appels dans un réseau de communication comprenant des terminaux nomades tels que des terminaux de téléphonie de type softphone
WO2015079153A1 (fr) Technique de restauration d'un service dans un réseau
WO2006134072A1 (fr) Procede de protection contre le piratage d'un terminal client utilisant une connexion securisee avec un serveur sur un reseau public
WO2021260290A1 (fr) Procedes et serveurs de gestion des services d'un terminal additionnel dans un reseau de coeur sip
WO2021105617A1 (fr) Procede d'assistance pour la gestion d'une attaque informatique, dispositif et systeme associes
FR3001351A1 (fr) Enregistrement d'un equipement client par l'intermediaire d'un serveur mandataire dans un reseau de communication
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
WO2018234662A1 (fr) Procédé de contrôle de l'obtention par un terminal d'un fichier de configuration
FR3110802A1 (fr) Procédé de contrôle de l’attribution d’une adresse IP à un équipement client dans un réseau de communication local, procédé de traitement d’une requête d’attribution d’une adresse IP à un équipement client dans un réseau de communication local, dispositifs, équipement d’accès, équipement serveur et programmes d’ordinateur correspondants.

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 14704851

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 14763461

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2014704851

Country of ref document: EP