EP1902564A2 - Mecanisme de protection des reseaux h.323 pour les fonctions d'etablissement d'appel - Google Patents

Mecanisme de protection des reseaux h.323 pour les fonctions d'etablissement d'appel

Info

Publication number
EP1902564A2
EP1902564A2 EP06779007A EP06779007A EP1902564A2 EP 1902564 A2 EP1902564 A2 EP 1902564A2 EP 06779007 A EP06779007 A EP 06779007A EP 06779007 A EP06779007 A EP 06779007A EP 1902564 A2 EP1902564 A2 EP 1902564A2
Authority
EP
European Patent Office
Prior art keywords
information element
token value
message
endpoint
token
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP06779007A
Other languages
German (de)
English (en)
Inventor
Patrick Battistello
Stéphane GORSE
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
France Telecom SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by France Telecom SA filed Critical France Telecom SA
Publication of EP1902564A2 publication Critical patent/EP1902564A2/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/101—Access control lists [ACL]
    • 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/1101—Session protocols
    • H04L65/1106—Call signalling protocols; H.323 and related

Definitions

  • the field of the invention is that the equipment and network architecture based on the H.323 series of Recommendations ITU-T I 1 "Packet Based Multimedia Communications Systems" and H.225 “CaII Signaling protocols and media stream packetization for packet -based multimedia communication systems ".
  • the invention relates more particularly to the security of networks that implement the H.323 protocol and the associated protocols, both from the operator and user point of view.
  • the control mechanisms defined in the H.323 series of Recommendations are not sufficient to mitigate certain vulnerabilities that have been demonstrated in the laboratory environment.
  • endpoints endpoint EPs
  • GK gatekeeper
  • the endpoints include terminals (terminal in English), gateways (GW for gateway in English), multipoint control units (MCUs for multipoint control unit in English), or more generally any entity capable of generating or receiving calls by processing associated information flows.
  • Admission procedures and calls for establishment implemented in these networks and entities defined in H.323 and H.225 Recommendations of I 1 ITU-T, are particularly sensitive because they are necessary for signaling transmission or reception of an audio-visual call.
  • the messages defined in Recommendations H.225 and H.323 are segmented into two functional groups: that of registration, admission and status named RAS (Registration Admission and Status) and the call signaling name CS (CallSignalling). Each of these groups has a network communication channel.
  • the messages considered are: a) For RAS functions:
  • Recommendation H.323 defines two main types of call establishment, according to CS group message routing.
  • a first mode is the communication control element routing mode named GKR for Gatekeeper Routed.
  • GKR the communication control element routing mode named GKR for Gatekeeper Routed.
  • a calling endpoint EP1 sends 1) an admission message ARQ to a control element GK1 with which it is registered.
  • the control element GK1 sends 2) localization LRQ messages to and receives LCF responses from the control element GK2 with which is registered the endpoint called EP2, possibly via other intermediate control elements GKi.
  • GK1 sends 3) to EP1 an ACF admission confirmation message.
  • EP1 sends 4) to GK1 a setup call setup message.
  • the message Setup is then relayed 5) between the various control elements up to GK2 which transmits it 6) to EP2.
  • EP2 On receipt of the Setup message, EP2 initiates an admission phase 7) with the control element GK2 with which it is registered.
  • the last phase 8) means to EP2 that it is allowed to accept the call.
  • a second mode is the direct mode which is named DIR.
  • the first three phases 1), 2) and 3) are identical to those of the GKR mode.
  • the difference is in phase 4) where the Setup message is sent directly to the endpoint called EP2, this being made possible by the destination address information returned in phase 3) in the ACF message.
  • the last two phases 7) and 8) are identical to the phases 7) and 8) of the GKR mode.
  • control elements GK1 and GK2 can optionally be interconnected via other control elements (GKj) according to the organic architecture.
  • GKj control elements
  • EP1 and EP2 are recorded on the same control element GK1 so that GK2 coincides with GK1;
  • the sending of LRQ message is a dynamic mechanism for locating the destination control element; this mechanism is optional and can be replaced by management plan functions. In addition, it is only useful when the two endpoints are not registered on the same control element;
  • Hybrid mode Although defined in the standard, the case where an endpoint is not registered with a control element is not taken into account because it does not correspond to an operational reality for audiovisual services deployed today. hui; • A third call setup mode is defined in the standard: Hybrid mode. In hybrid mode, some network control elements apply GKR mode while others apply DIR mode. Since at least one network element is involved in call setup, the hybrid mode is functionally assimilated to the GKR mode.
  • the message processing functions of the RAS group and those of the processing of the Setup messages can be distributed among various elements or equipments of the network. This distribution potentially having impacts on the security of the audiovisual service, there are three organic architectures.
  • a first so-called Al architecture is one in which the processing functions RAS and CS are integrated within the same equipment 1 with the possibility of complete correlation between the fields of the messages RAS and / or CS.
  • the equipment 1 is generally a control element GK.
  • a second so-called AR architecture is one in which the RAS processing functions are carried out in the equipment 1, whereas the processing functions CS are carried out in a device 2.
  • the CS messages are sent directly to the device 1. 2 or optionally pass through the equipment 1.
  • the CS messages can optionally be processed by a CS pre-module in the equipment 1.
  • This pre-module module typically performs filtering, address translation, syntax checking, or partial correlation with RAS functions.
  • a third architecture called AF is that in which the processing functions RAS are carried out in the equipment 2, whereas the processing functions CS are carried out in a device 3.
  • the equipment 1 plays a role of front end by relaying the RAS messages to the equipment 2 and the CS messages to the equipment 3.
  • processing by a pre-module RAS or a pre-module CS can be performed in the equipment 1, such as filtering, address translation, syntax checking or partial correlation RAS / CS.
  • the main role of the equipment 1 remains to protect the equipment 2 and 3 by preventing their direct access from the end point, that is to say the customer.
  • the attack consists, for a customer subscribed to an audio-visual service, to emit a call by modifying its identity, typically by changing the number of call which the operator has attributed to it in another number, which may be unallocated or assigned to a third party customer.
  • this attack can also have consequences on the billing in the case where the attacker uses as a source number that of an existing client.
  • A1 mode is to change the calling number at the ARQ message level. This is possible in systems whose RAS function does not correlate the [endpointidentifier] and [srclnfo] fields of the ARQ message allowing an endpoint to use a calling number that does not match its registration number. This spoofed number must then be reported by the attacker in the [sourceAddress] field of the Setup message.
  • the A2 mode is to send a correct ARQ message with respect to the [srclnfo] field, and then change this number to a usurped number when issuing the Setup message since the latter message is the basis of the establishment. 'call.
  • This attack is possible when the CS function does not correlate the [sourceAddress] field of the Setup message with the [srclnfo] field of the ARQ message.
  • the attack consists, for a non-subscriber to an audio-visual service, to make a call on the network of the operator, without being charged for this call.
  • the attacker can usually use any calling number, which can be unallocated or assigned to a regular customer.
  • This attack generates a shortfall for the operator and moreover it poses a billing problem in the case where it uses a calling number already allocated.
  • A3 mode an attacker sends a Setup message directly to the CS function of the network that is in charge of establishing the call. This is the simplest case and it usually allows the attacker to set the calling number and the called number to any values.
  • This attack assumes that the CS function does not check that a prior ARQ message has been sent and that the user has the right to send a Setup message. Although an easier realization in the AR and AF architectures, this attack is also found in the Al architecture.
  • the attacker sends a Setup message following an ARQ / ACF exchange initiated by a corrupt client, ie a customer subscribed to the service but collaborating with one or more attackers.
  • the corrupt client sends an ARQ message and, upon receipt of the ACF message, transfers to the attacker the information necessary for it to send the Setup message.
  • the network correlates the Setup message with the ARQ message as belonging to the same dialog, whereas these messages come from two different entities.
  • the Setup message may contain a usurped calling number with the same consequences as previously mentioned.
  • the mechanism M1 implements firewall equipment which, upstream of the equipment carrying the H.323 functions RAS and CS, mainly performs packet filtering on the basis of address and port information. In some cases, this mechanism performs state filtering on H.323 messages, for example by allowing a Setup message only if preceded by an ARQ / ACF exchange. So this mechanism against direct attack type A3 but it is generally inefficient against more sophisticated attacks that exploit the lack of correlation between certain fields of the ARQ messages and Setup.
  • the M2 mechanism is based on dynamic port usage.
  • the A3 attack is often made possible by the use of a fixed listening port (usually port 1720) for the CS function of the network, the idea here is to use a different port can also be dynamic.
  • This new port is communicated to regular customers via the ACF message, which assumes that these terminals are registered to the service, unlike a non-legitimate user who would send directly the Setup message on the port 1720 of the H.323 CS equipment.
  • This mechanism is effective against the A3 attack, but ineffective against more elaborate attacks.
  • the M3 mechanism analyzes a degree of correlation between ARQ and Setup messages.
  • the idea is to strictly check some fields detected as sensitive within the ARQ and Setup messages.
  • a first level of rules checks the intra message fields (ARQ and Setup) while a second level of rules checks the inter message fields (between ARQ and Setup).
  • ARQ and Setup checks the intra message fields
  • a second level of rules checks the inter message fields (between ARQ and Setup).
  • the patent application FR0502110 brings improvements to the standard in terms of security by teaching several verification rules for ARQ and Setup messages. These rules make it possible to parry the A1 to A4 attacks in the context of an Al architecture. However, they are not easy to implement in the AR and AF architectures where the RAS and CS functions of the network are not co-located, which makes the level of checking inter messages much more complex.
  • the mechanism M4 is based on a control token which consists essentially of an information element transmitted and / or relayed between several entities.
  • the RAS that receives the ARQ message, associates the ACF message with a random token that has a limited validity period, and then verifies that the endpoint correctly regenerates this token in the Setup message.
  • This mechanism is interesting to fight the A3 attack.
  • it presents a substantial weakness, namely that of allowing a corrupt client to communicate this token to one or more attackers who inherently have the right to send Setup messages.
  • this token being generally random or fixed, according to the prior art, it is not satisfactory to achieve the correlation between the sensitive fields highlighted in the mechanism M3.
  • the M5 mechanism implements an authentication process.
  • Sensitive messages such as ARQ and Setup must include client authentication.
  • Authentication processes are many and varied, but usually based on a login with password specific to each client.
  • the operational disadvantage of this mechanism is in its implementation which requires authentication servers.
  • this mechanism poses the problem of being able to support an increase in load when the number of customers is high. In practice and for performance reasons, it is difficult or impossible to authenticate all messages.
  • Another disadvantage, theoretically, is that the authentication is not related to the sensitive parameters of the messages, and so it is always possible, even for an authenticated client, to change certain parameters of the dialogue and so on. create vulnerabilities in the network. Finally, one could imagine a corrupt customer disclosing its authentication settings to non-subscribers to the service, in the continuation of the A4 attack.
  • a first objective of the invention is to parry the types of attacks A1 to A4, by protecting the parameters of the dialogue prior to call establishment against fraudulent modifications and by controlling a strong state of correlation between the messages transmitted in the part of a call establishment.
  • a second objective of the invention is to be applicable to AR and AF architectures as well as to Al type architectures, ie to make possible the correlation between the ARQ and Setup messages even in the cases where the RAS and CS functions are organically disjoint.
  • a third object of the invention is to be applicable to both the GKR call establishment mode DIR call setup mode or a combination of these two modes.
  • a first object of the invention is a method of securing a network in which to establish a call to a called endpoint, a calling endpoint transmits, a call establishment message comprising a call element.
  • source information and a destination information element each having a signaling value which respectively identifies the calling endpoint and the called endpoint.
  • the method is remarkable in that the network establishes said call provided that said signaling values correspond to admission values previously brought to the knowledge of the network.
  • said knowledge is included in a token whose network verifies that a first value transmitted in the call establishment message corresponds to a second token value given by an equation which comprises said elementary signaling values.
  • the first token value is computed by a functional group called registration, admission and status within the calling-side network by means of said equation when said functional group receives a request message. an admission from a transmitting endpoint, said request message containing a destination information element and a source information element identifying said transmitting endpoint. Said functional group then sends to the sending endpoint an admission confirmation message containing said first token value.
  • a call signaling functional group within the network receives the call setup message, verifies that the setup message contains the first token value and searches for the element random information associated with said first token value, and if successful, calculates the second token value by said equation so as to verify that said first token value is equal to said second token value.
  • a so-called registration, admission and status functional group within the called-side network receives an admission request message from the called endpoint, said admission request message comprising a source information element and a destination information element identifying the called endpoint, verifies that the admission request message contains the first token value and searches for the random information element associated with said first token value, and if successful, calculates the second token value by said equation so as to send an admission confirmation message to the called endpoint provided that said first token value is equal to said second token value.
  • a second object of the invention is a control element of a network in which to establish a call to a called endpoint, a calling endpoint transmits, a call establishment message comprising a call element.
  • source information and a destination information element each having a signaling value which respectively identifies the calling endpoint and the called endpoint.
  • the control element is remarkable in that it comprises means for establishing said call provided that said signaling values correspond to admission values previously brought to the knowledge of the network.
  • the control element comprises means for verifying that a first token value transmitted in the call establishment message corresponds to a second token value given by an equation which comprises said elementary signaling values.
  • An H.323 type control element advantageously comprises a so-called registration, admission and status functional group arranged to receive an admission request message from a transmitting endpoint, to extract from said request message a destination information element and a source information element identifying said transmitting endpoint, for calculating said first token value by said equation, and for sending to the transmitting endpoint a confirmation message d admission containing said first token value.
  • the same control element or another control element comprises a so-called call signaling functional group arranged to receive the call setup message, to verify that the message of facility holds the first token value and searches for the random information element associated with said first token value, for successively calculating the second token value by said equation, and for verifying that said first token value is equal to said second token value.
  • one of the above control elements or another control element comprises a functional group called registration, admission and status arranged to receive an admission request message from the called endpoint, said admission request message comprising a source information element and a destination information element identifying the called endpoint, to verify that the admission request message contains the first token value and search for the random information element associated with said first value of token, for calculating on success the second token value by means of said equation, and for sending an admission confirmation message to the called endpoint provided that said first token value is equal to said second value of token.
  • a control element By being arranged to destroy an association between random information element and first token value after positive verification of correspondence between the first and second token value, a control element opposes multiple use of the same first value. of token.
  • FIG. 1 shows a call setup scheme in routed mode
  • FIGS. 3 to 5 illustrate various organic architectures for processing call setup messages
  • FIG. 6 is a block diagram of implementation of a method according to the invention in routed mode
  • FIG. 7 presents a block diagram of implementation of the method according to the invention in direct mode
  • FIGS. 8 to 15 show examples of call setup detected valid by the method according to the invention.
  • FIGS. 16 to 19 show examples of call setup detected fraudulent by the method according to the invention.
  • ASA source address
  • srclnfo One or more aliases for the calling endpoint. These aliases can be a phone number, an e164 identifier, an H.323 identifier, an e-mail address or other. The type of alias used has no impact on the described method. Status of this field: required
  • SCA srcCallSignalAddress
  • DCA destCallSignalAddress
  • sourceAddress SAS
  • SIA SIA field for the Setup message. Status of this field: optional if SCS present
  • SCS SCA field for the Setup message.
  • DAS destinationAddress
  • DIA DIA field for the Setup message.
  • DCS DCS present
  • DCS destCallSignalAddress
  • a method according to the invention implements a token mechanism incorporating certain ARQ and Setup message information that is security sensitive.
  • the block diagram presented in FIG. 6 makes it possible to describe in detail the token mechanism in GKR mode as we know it with reference to FIG. 1.
  • the RAS function receives an ARQ request message 1) in the equipment call-side network
  • the RAS function checks first whether this request is acceptable or not. This verification is based on the principles of Recommendations H.323 and H.225 for call admission and advantageously on additional consistency rules for ARQ messages such as those defined in patent application FR 05 02110. If the verification is positive, the caller-side RAS function generates a token J, on the basis of a so-called random information element A, an element called IS of source information and a so-called information element ID of destination. The IS and ID elements are derived from the ARQ message.
  • step 2) the calling side RAS function transfers the elements A and J to the first function CS resident in the network equipment in charge of subsequently receiving the Setup message.
  • step 3 the calling side RAS returns an ACF message containing the token J to the calling endpoint which, in step 4), sends a Setup message completed by the token J.
  • the message Setup is sent to the first function CS which is in charge of routing the call.
  • the transport address to which the Setup message is to be sent is determined by the network elements and indicated to the calling terminal in the content of the ACF message.
  • the validity of the Setup message with respect to the token J is verified by the first function CS.
  • the block diagram presented in FIG. 7 makes it possible to describe in detail the token mechanism in DIR mode as we know it with reference to FIG. 2.
  • the RAS function receives an ARQ request message 1) in the equipment. Calling-side network, the RAS function checks first whether this request is acceptable or not in a similar way to that of the GKR mode.
  • the calling side RAS function transfers elements A and J to the RAS function residing in the called-side network equipment.
  • the calling side RAS returns an ACF message containing the token J to the calling endpoint which, in a step 4), sends a Setup message completed by the token J.
  • the Setup message is sent directly to the called terminal.
  • the transport address to which the Setup message is to be sent is determined by the network elements and indicated to the calling terminal in the content of the ACF message.
  • the called endpoint sends an ARQ message 7) based on the information of the Setup message and containing the token J, to the called-side network equipment.
  • the ARQ message is checked by the called-side RAS function which generates an ACF confirmation message 8) to accept the call if the check is positive.
  • the information element A is a random number that can be numeric or alpha numeric in nature and of any length. This element applies to one and only one token, so it is generated randomly with each new token calculation.
  • a set value of IS information element is determined from the ARQ message received by the calling side RAS function and is governed by the equation:
  • IS SIA + ASA + SCA
  • the sign '+' designates the concatenation operator, and the acronyms SIA, ASA and SCA are those previously defined.
  • ASA and SCA fields refer to only at the network address and not at the associated port. If the SCA field is not included in the ARQ message, it takes the empty value in the previous equation.
  • a value of the information element ID, called establishment code, is determined from the ARQ message received by the calling side RAS function and is governed by the equation:
  • DIA + DCA DIA + DCA
  • the sign '+' designates the concatenation operator, and the initials DIA and DCA are those previously defined.
  • the DCA field refers only to the network address and not to the associated port. Since the DIA and DCA fields are mutually optional, if one of them is not included in the ARQ message, it takes the empty value in the previous equation.
  • the token J is generated by the calling side RAS function and its value is governed by the equation:
  • J hash (A + IS + ID) where '+' is the concatenation operator and 'hash' is a hash function, such as the known algorithm MD5, which returns a string of fixed-size characters. While the information element A is random, the elements IS and ID depend only on the current call.
  • the token J and the information element A are transferred by the calling side RAS function to the entity in charge of carrying out the verification function.
  • This destination entity may be a CS function ("GKR” mode) or the called side RAS function ("DIR” mode). It is indicated that the called side RAS function may coincide with the calling side RAS function in the case where the calling and called endpoints are registered with the same control element and the call setup is direct (“DIR" mode). ").
  • the message LRQ will be chosen because it is used nominally between the H.323 entities to locate the called endpoint and determine the transport address to which the Setup message is to be sent.
  • the message mode can be applied to all cases of implementation.
  • the entity receiving information A and J is responsible for storing them in a token database and then deleting the corresponding record when one of the following two rules is verified: • Use: information A and J have been extracted from the base to serve as verification, following the receipt of a Setup or ARQ message carrying a token of the same value as J. This rule applies if the result of the verification is positive. It is best not to destroy the token in case of negative verification so as not to prevent an authorized endpoint from using the token;
  • Expiration Information A and J were not used after an operator defined storage time. This storage time is typically equal to the maximum allowable time between receipt of the ARQ message and receipt of the associated Setup message.
  • the first condition is typically used to avoid replay attacks by ensuring that a token can only be used once and only once, while the second condition avoids overhead attacks by storing "indefinitely" a large number of replay attacks. chips in the system.
  • the CS function of the network entity receiving the Setup message from the calling endpoint retrieves the J token from this message and seeks a match with a token of the same value stored in its token base. . If a match is found, the entity retrieves the piece of information Associated with this token in the base, otherwise the token is considered invalid and the call is rejected.
  • a source of information SI value R and a destination information element ID value R are determined from the setup of call setup message.
  • DCA its own transport address for the CS channel
  • the called-side RAS function seeks a correspondence between the received token J and a token of the same value recorded in its base.
  • a source information element value IS R and a destination information element element ID R are determined from the ARQ message 7).
  • J R hash (A + IS R + ID R ) where:
  • ID R DIA + DCA (with DIA and DCA as defined above)
  • the call establishment can continue and an ACF 8) is sent to the called party, otherwise the call establishment fails and an ARJ message is sent to the called party. 'called.
  • the fields sent by the called party in the ARQ message 7 must be similar and of the same format as those sent by the caller in the ARQ message 1).
  • the field DIA must be simultaneously present or simultaneously absent in these two messages, as well as the field DCA,
  • the mechanism described in the preceding paragraphs consists, from a valid ARQ request, to communicate to the corresponding CS function IS and ID call identification elements allowing it to validate the expected Setup message.
  • an alternative mechanism is to directly transfer the IS and ID information to the CS function that is supposed to receive the Setup message. In this case, the transfer of the token J in the messages ACF 3), Setup 4) and ARQ 7) is no longer necessary.
  • the mechanism described in the preceding paragraphs can easily be transposed to the verification of Setup messages sent between control elements in the case of inter-domain call setup.
  • the control element that sends the Setup message calculates a J token associated with this Setup and transfers the information A, J to the control element that is supposed to receive the Setup.
  • the transfer of this information can be done via a proprietary mechanism or advantageously by using an H.323 signaling message such as the LRQ message.
  • the control element receiving the Setup extracts the information J that it contains, and if the token J is present in its base of chips, it carries out the verification, as described previously to know if it can accept the message Setup.
  • Figure 8 shows a valid call in GKR mode in an Al architecture where the endpoints are on the same GK. Details:
  • ARQ 1 .1.15 H '
  • SIA 1 123'
  • SCA 1 LI .1.10 1
  • DIA 1 134 '
  • DCA "
  • the ARQ message 1) must not contain an SCA parameter so that the two tokens can be compared;
  • the SCS field of the Setup 4 message is not reported in the ARQ message 7), however it is important to correlate its value with the source address of the Setup message;
  • the caller does not use the DCA field of the ARQ message, the caller must also not use it so that the comparison of chips has a meaning.
  • Figure 10 shows a valid GKR call in an Al architecture where the endpoints are on two separate GKs. Details:
  • GK1 may possibly initiate a 2) LRQ / LCF exchange with GK2 to locate the called endpoint.
  • Figure 11 shows a valid call in GKR mode in an Al architecture where the endpoints are on two separate control elements and where the calling side control element GK1 decides not to route the call. Details:
  • GK2 gives its own address because it decides to route the call; - as at least one of the control elements GK1 or GK2 has decided to route the call, the resulting mode is "GKR", although GK1 is in direct mode.
  • Figure 12 shows a valid call in DIR mode in an Al architecture where the endpoints are on two separate control elements. Details:
  • Figure 13 shows a valid call in GKR mode in an AR architecture where the endpoints are on the same control element with distribution of the RAS and CS functions respectively on a Equip.1 equipment and Equip.2 equipment.
  • ASA 1 L 1.1.10 '
  • SIA 1 123'
  • SCA 1 LLLIO 1
  • DIA 1 134 '
  • DCA "
  • Figure 14 shows a valid call in GKR mode in an AR architecture where the endpoints are on the same control element with distribution of the RAS and CS functions respectively on Equip.1 equipment and Equip.2 equipment.
  • the variant consists in that the equipment 1 performs CS prefunctions, in particular the verification of the token and the relay of the Setup message which is no longer sent directly to the equipment 2. Details:
  • the sending of the ACF message 3) by the equipment 1 may be preceded by a LRQ / LCF phase during which the equipment 1 verifies that the equipment 2 is ready to receive the Setup message;
  • the extension of the call establishment is the responsibility of the equipment 2.
  • FIG. 15 shows a valid call in GKR mode in an AF architecture where the endpoints are recorded on the same control element with Equip.1 front end equipment and distribution of the RAS and CS functions respectively on Equip.2 equipment and on equipment Equip.3. Details:
  • ARQ 1 .1.1 H '
  • SIA 1 123'
  • SCA 1 LLLI 1
  • DIA 1 134 '
  • DCA "
  • ASS 1 LLLIO 1
  • SAS '123'
  • SCS 1 LLLIO 1
  • DAS '134'
  • DCS 1 LLLI 1 ,
  • Phase 6 is normally extended by an exchange ARQ / ACF between EP2 and the equipment 2 (phase not shown here because not included in the process);
  • Figure 16 shows a fraudulent call in GKR mode in Al architecture with attempted impersonation by a regular customer.
  • the calling phone number can be set to any value, it may or may not coincide with a number already registered (impersonation);
  • FIG. 18 shows a fraudulent call in GKR mode in an Al architecture with attempted free access to the service.
  • This example is based on an "ARQ Relay" attack where the attacker has the complicity of a "corrupt client", ie a subscriber to the service capable of reading the H.323 signaling messages. that are returned to the network and to communicate certain key information to a non-subscriber. The attacker will usually use a different caller number than the "corrupted client".
  • the "corrupt client" who has received the ACF can also transfer other information relating to the call such as identifiers [callldentifier], [conferencelD ];
  • Figure 19 shows a fraudulent call in GKR mode in an Al architecture attempting free access to the service. This example is based on the same principle as the previous one, but in the case of the direct call setup mode. Details:

Landscapes

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

Abstract

Dans un réseau où pour établir un appel vers un point d'extrémité appelé, un point d'extrémité appelant émet (4) à destination du point d'extrémité appelé, un message d'établissement d'appel comprenant un élément d'information de source identifiant le point d'extrémité appelant et un élément d'information de destination identifiant le point d'extrémité appelé, l'appel est établi à condition que le message d'établissement d'appel contienne une première valeur de jeton (J) qui correspond à une deuxième valeur de jeton donnée par une équation qui comprend ledit élément d'information de source, ledit élément d'information de destination et un élément d'information aléatoire généré par le réseau pour être associé secrètement dans le réseau à la première valeur de jeton.

Description

Mécanisme de protection des réseaux H .323 pour les fonctions d'établissement d'appel.
Le domaine de l'invention est celui des équipements et architectures de réseaux basés sur la série de Recommandations H.323 de I1UIT-T "Packet Based multimédia communication Systems" et H.225 "CaII Signalling protocols and média stream packetization for packet-based multimédia communication Systems".
L'invention concerne plus particulièrement la sécurité des réseaux qui mettent en œuvre le protocole H.323 et les protocoles associés, tant du point de vue opérateur qu'utilisateur. Les mécanismes de contrôle définis dans la série de Recommandations H.323, ne suffisent pas à pallier certaines vulnérabilités dont la démonstration a été faite en environnement de laboratoire.
Parmi les entités de réseau définis dans la recommandation H.323, on considère les points d'extrémités (EP pour endpoint en anglais) et les éléments de contrôle des communications (GK pour gatekeeper en anglais). Les points d'extrémités comprennent des terminaux (terminal en anglais), des passerelles (GW pour gateway en anglais), des unités de contrôle multipoint (MCU pour multipoint control unit en anglais), ou plus généralement toute entité capable de générer ou recevoir des appels en traitant les flux d'informations associés.
Les procédures d'admission et d'établissement d'appels mises en oeuvre dans ces réseaux et entités définies dans les Recommandations H.323 et H.225 de I1ITU-T, sont particulièrement sensibles puisqu'elles portent la signalisation nécessaire à l'émission ou la réception d'un appel audio-visuel.
Dans l'état actuel de la normalisation des fonctions d'admission et d'établissement d'appels, on connaît différents modèles d'établissement d'appels et différentes architectures organiques.
A propos des modèles d'établissement d'appel, les messages définis dans les Recommandations H.225 et H.323 sont segmentés en deux groupes fonctionnels : celui d'enregistrement, admission et statut nommé RAS (Registration Admission and Status) et celui de signalisation d'appel nomé CS (CallSignalling). A chacun de ces groupes correspond un canal de communication réseau. Les messages considérés sont : a) Pour les fonctions RAS :
• Ceux de requête d'admission nommés ARQ (Admission ReQuest), ceux de confirmation d'admission nommés ACF (Admission ConFirm), ceux de déni d'admission nommés ARJ (Admission ReJect)
• Ceux de requête de localisation nommés LRQ (Location ReQuest), ceux de confirmation de localisation nommés LCF (Location ConFirm) et ceux de déni de localisation nommés LRJ (Location ReJect) b) Pour les fonctions CS :
• Ceux d'établissement d'appel nommés Setup.
La Recommandation H.323 définit deux principaux modes d'établissement d'appel, selon le routage des messages du groupe CS.
Un premier mode est le mode de routage par éléments de contrôle des communications nommé GKR pour "Gatekeeper Routed" en anglais. En référence à la figure 1 , pour appeler un point d'extrémité EP2, un point d'extrémité appelant EP1 envoie 1) un message d'admission ARQ vers un élément de contrôle GK1 auprès duquel il est enregistré. L'élément de contrôle GK1 envoie 2) des messages LRQ de localisation vers et reçoit des réponses LCF de l'élément de contrôle GK2 auprès duquel est enregistré le point d'extrémité appelé EP2, via éventuellement d'autres éléments de contrôle intermédiaires GKi. Suite à réception de réponse LCF, GK1 envoie 3) vers EP1 un message de confirmation d'admission ACF. A réception du message ACF, EP1 envoie 4) vers GK1 un message d'établissement d'appel Setup. Le message Setup est alors relayé 5) entre les différents éléments de contrôle jusqu'à GK2 qui le transmet 6) vers EP2. A la réception du message Setup, EP2 initie une phase d'admission 7) avec l'élément de contrôle GK2 auprès duquel il est enregistré. La dernière phase 8) signifie à EP2 qu'il est autorisé à accepter l'appel. Un deuxième mode est le mode direct qui est nommé DIR. En référence à la figure 2, les trois premières phases 1 ), 2) et 3) sont identiques à celles du mode GKR. La différence se situe en phase 4) où le message Setup est envoyé directement au point d'extrémité appelé EP2, ceci étant rendu possible par les informations d'adresse de destination retournées en phase 3) dans le message ACF. Les deux dernières phases 7) et 8) sont identiques aux phases 7) et 8) du mode GKR.
Aussi bien dans le mode GKR que DIR :
• Le choix du mode GKR ou DIR est à la charge de l'élément de contrôle et non du point d'extrémité. Cependant, le point d'extrémité peut exprimer une préférence;
• Les éléments de contrôle GK1 et GK2 peuvent optionnellement être interconnectés via d'autres éléments de contrôle (GKj) suivant l'architecture organique. Dans le cas le plus simple, EP1 et EP2 sont enregistrés sur le même élément de contrôle GK1 de sorte que GK2 coïncide avec GK1 ;
• L'envoi de message LRQ est un mécanisme dynamique pour localiser l'élément de contrôle de destination ; ce mécanisme est optionnel et peut être remplacé par des fonctions de plan de gestion. De plus, il n'est utile que lorsque les deux points d'extrémité ne sont pas enregistrés sur le même élément de contrôle;
• Bien que défini dans la norme, le cas où un point d'extrémité n'est pas enregistré auprès d'un élément de contrôle n'est pas pris en compte car ne correspondant pas à une réalité opérationnelle pour les services audiovisuels déployés aujourd'hui; • Un troisième mode d'établissement d'appel est défini dans la norme : le mode hybride. En mode hybride, certains éléments de contrôle du réseau appliquent le mode GKR alors que d'autres appliquent le mode DIR. Comme au moins un élément de réseau est impliqué dans l'établissement d'appel, le mode hybride est fonctionnellement assimilé au mode GKR.
Suivant les choix d'architecture et les contraintes opérationnelles, les fonctions de traitement des messages du groupe RAS et celles de traitement des messages Setup peuvent être réparties entre divers éléments ou équipements du réseau. Cette répartition ayant potentiellement des impacts sur la sécurité du service audiovisuel, on distingue trois architectures organiques.
En référence à la figure 3, une première architecture dite Al est celle où les fonctions de traitements RAS et CS sont intégrées au sein d'un même équipement 1 avec possibilité de corrélation complète entre les champs des messages RAS et/ou CS. Dans cette architecture, l'équipement 1 est généralement un élément de contrôle GK.
En référence à la figure 4, une deuxième architecture dite AR est celle où les fonctions de traitement RAS sont réalisées dans l'équipement 1 , alors que les fonctions de traitement CS sont réalisées dans un équipement 2. Les messages CS sont envoyés directement vers l'équipement 2 ou optionnellement transitent via l'équipement 1. Lorsqu'ils transitent via l'équipement 1 , les messages CS peuvent optionnellement faire l'objet d'un traitement par un pré-module CS dans l'équipement 1. Ce pré-module réalise typiquement des fonctions de filtrage, translation d'adresses, vérification de syntaxe ou corrélation partielle avec les fonctions RAS.
En référence à la figure 5, une troisième architecture dite AF est celle où les fonctions de traitement RAS sont réalisées dans l'équipement 2, alors que les fonctions de traitement CS sont réalisées dans un équipement 3. L'équipement 1 joue un rôle de frontal vis-à-vis du point d'extrémité en relayant les messages RAS vers l'équipement 2 et les messages CS vers l'équipement 3. Optionnellement des traitements par un pré-module RAS ou un pré-module CS peuvent être réalisés dans l'équipement 1 , tels que filtrage, translation d'adresses, vérification de syntaxe ou corrélation partielle RAS/CS. Le rôle principal de l'équipement 1 reste de protéger les équipements 2 et 3 en empêchant leur accès direct depuis le point d'extrémité, c'est-à-dire le client.
La conformité aux recommandations H.323 et H.225 dans leur état actuel, ne suffit pas à immuniser les réseaux H.323 lors de l'établissement d'appel, contre certaines attaques visant à une usurpation d'identité et à un accès gratuit au service. La réalisation de telles attaques a été mise en évidence par les inventeurs en environnement de laboratoire sur certains systèmes conformes aux recommandations du point de vue de la sécurité.
A propos de l'usurpation d'identité, l'attaque consiste, pour un client abonné à un service audio-visuel, à émettre un appel en modifiant son identité, typiquement en changeant le numéro d'appel que lui a attribué l'opérateur en un autre numéro, pouvant être non attribué ou attribué à un client tiers. En plus du problème de non intégrité posé au service audio-visuel, cette attaque peut également avoir des conséquences sur la facturation dans le cas où l'attaquant utilise comme numéro source celui d'un client existant.
A titre illustratif, on peut citer deux modes A1 et A2 de réalisation de cette attaque. Le mode A1 consiste à modifier le numéro appelant au niveau du message ARQ. Cela est possible dans les systèmes dont la fonction RAS ne corrèle pas les champs [endpointldentifier] et [srclnfo] du message ARQ permettant à un point d'extrémité d'utiliser un numéro appelant qui ne correspond pas à son numéro d'enregistrement. Ce numéro usurpé doit ensuite être reporté par l'attaquant dans le champ [sourceAddress] du message Setup. Le mode A2 consiste à émettre un message ARQ correct en ce qui concerne le champ [srclnfo], puis à changer ce numéro en un numéro usurpé lors de l'émission du message Setup puisque ce dernier message est à la base de l'établissement d'appel. Cette attaque est possible lorsque la fonction CS ne corrèle pas le champ [sourceAddress] du message Setup avec le champ [srclnfo] du message ARQ. Bien que d'une réalisation plus aisée dans les architectures AR et AF, cette attaque se rencontre également dans l'architecture Al.
A propos de l'accès gratuit au service, l'attaque consiste, pour un internaute non abonné à un service audio-visuel, à émettre un appel sur le réseau de l'opérateur, sans être facturé pour cet appel. Lorsqu'il y parvient, l'attaquant pourra généralement utiliser un numéro appelant quelconque, pouvant être non attribué ou au contraire attribué à un client régulier. Cette attaque génère un manque à gagner pour l'opérateur et de plus elle pose un problème de facturation dans le cas où elle utilise un numéro appelant déjà attribué.
A titre illustratif, on peut citer deux modes A3 et A4 de réalisation de cette attaque. Dans le mode A3, un attaquant envoie directement un message Setup à la fonction CS du réseau qui est en charge de l'établissement d'appel. C'est le cas le plus simple et il permet généralement à l'attaquant de positionner le numéro appelant et le numéro appelé à n'importe quelles valeurs. Cette attaque suppose que la fonction CS ne vérifie pas qu'un message ARQ préalable ait été envoyé et que l'internaute a effectivement le droit d'envoyer un message Setup. Bien que d'une réalisation plus aisée dans les architectures AR et AF, cette attaque se rencontre également dans l'architecture Al. Dans le mode A4, l'attaquant envoie un message Setup à la suite d'un échange ARQ/ACF initié par un client corrompu, c'est à dire un client abonné au service mais collaborant avec un ou plusieurs attaquants. Ainsi, le client corrompu envoie un message ARQ puis, sur réception du message ACF, transfère à l'attaquant les informations nécessaires pour que celui-ci puisse envoyer le message Setup. Le réseau corrèle le message Setup avec le message ARQ comme appartenant au même dialogue, alors que ces messages proviennent de deux entités différentes. De plus, le message Setup peut contenir un numéro appelant usurpé avec les mêmes conséquences que précédemment évoquées. Bien que d'une réalisation plus aisée dans l'architecture AF, cette attaque se rencontre également dans les architectures AR et Al.
On connaît principalement cinq mécanismes de protection noté ci-après M1 à M5 pour parer les attaques de type A1 à A4.
Le mécanisme M1 met en œuvre un équipement pare-feu qui, placé en amont des équipements portant les fonctions H.323 RAS et CS, réalise principalement du filtrage de paquets sur la base d'information d'adresses et de ports. Dans certains cas, ce mécanisme réalise un filtrage à états sur les messages H.323 en n'autorisant par exemple un message Setup que s'il est précédé d'un échange ARQ/ACF. Ainsi ce mécanisme contre l'attaque directe de type A3, mais il est généralement inefficace contre les attaques plus élaborées qui exploitent l'insuffisance de corrélation entre certains champs des messages ARQ et Setup.
Le mécanisme M2 repose sur une utilisation de port dynamique. L'attaque A3 étant souvent rendue possible par l'utilisation d'un port d'écoute fixe (habituellement le port 1720) pour la fonction CS du réseau, l'idée consiste ici à utiliser un port différent pouvant de plus être dynamique. Ce nouveau port est communiqué aux clients réguliers via le message ACF, ce qui suppose que ces terminaux soient enregistrés au service, contrairement à un internaute non légitime qui enverrait directement le message Setup sur le port 1720 de l'équipement H.323 CS. Ce mécanisme est efficace contre l'attaque A3, mais inefficace contre les attaques plus élaborées. De plus, il est facile à un client corrompu de transmettre à un ou plusieurs attaquants, la nouvelle valeur du port utilisé, même si celui-ci est dynamique et change fréquemment.
Le mécanisme M3 analyse un degré de corrélation entre les messages ARQ et Setup. L'idée est de vérifier de façon stricte certains champs détectés comme sensibles au sein des messages ARQ et Setup. Un premier niveau de règles vérifie les champs intra message (ARQ et Setup) alors qu'un second niveau de règles vérifie les champs inter messages (entre ARQ et Setup). Ainsi, la demande de brevet FR0502110 apporte des améliorations à la norme sur le plan de la sécurité en enseignant plusieurs règles de vérification pour les messages ARQ et Setup. Ces règles permettent de parer les attaques A1 à A4 dans le contexte d'une architecture Al. Cependant elles ne sont pas aisées à mettre en oeuvre dans les architectures AR et AF où les fonctions RAS et CS du réseau ne sont pas co- localisées, ce qui rend le niveau de vérification inter messages beaucoup plus complexe.
Le mécanisme M4 repose sur un jeton témoin qui consiste essentiellement en un élément d'information transmis et/ou relayé entre plusieurs entités. Selon ce mécanisme, l'entité RAS qui reçoit le message ARQ, associe au message ACF un jeton aléatoire qui a une durée de validité limitée, et vérifie ensuite que le point d'extrémité régénère correctement ce jeton dans le message Setup. Ce mécanisme est intéressant pour lutter contre l'attaque A3. Cependant, dans l'état actuel de connaissance, il présente une faiblesse substancielle, à savoir celle de permettre à un client corrompu de communiquer ce jeton vers un ou plusieurs attaquants qui gagneront intrinsèquement le droit d'envoyer des messages Setup. D'autre part, ce jeton étant généralement aléatoire voire fixe, selon l'état antérieur de la technique, il n'est pas satisfaisant pour réaliser la corrélation entre les champs sensibles mis en évidence dans le mécanisme M3.
Le mécanisme M5 met en œuvre un processus d'authentification. Les messages sensibles tels que ARQ et Setup doivent inclure une authentification du client. Les processus d'authentifications sont nombreux et variés, mais généralement basés sur un identifiant avec mot de passe propres à chaque client. L'inconvénient opérationnel de ce mécanisme est dans sa mise en oeuvre qui nécessite des serveurs d'authentification. D'autre part, ce mécanisme pose le problème de pouvoir supporter une montée en charge lorsque le nombre de clients est élevé. En pratique et pour des raisons de performances, il est difficile voire impossible d'authentifier tous les messages. Un autre inconvénient, d'ordre théorique, tient au fait que l'authentification n'est pas liée aux paramètres sensibles des messages, et ainsi qu'il est toujours possible, même pour un client authentifié, de modifier certains paramètres du dialogue et ainsi créer des vulnérabilités dans le réseau. Enfin, on pourrait imaginer un client corrompu divulguant ses paramètres d'authentification à des internautes non abonnés au service, dans le prolongement de l'attaque A4.
Un premier objectif de l'invention est de parer les types d'attaques A1 à A4, en protégeant les paramètres du dialogue préalable à un établissement d'appel contre des modifications frauduleuses et en contrôlant un état fort de corrélation entre les messages émis dans le cadre d'un établissement d'appel.
Un deuxième objectif de l'invention est d'être applicable autant à des architectures de type AR et AF qu'à des architectures de type Al, c'est à dire de rendre possible la corrélation entre les messages ARQ et Setup même dans les cas où les fonctions RAS et CS sont organiquement disjointes. Un troisième objectif de l'invention est d'être applicable aussi bien au mode d'établissement d'appel GKR qu'au mode d'établissement d'appel DIR ou qu'à une combinaison de ces deux modes.
Un premier objet de l'invention est un procédé de sécurisation d'un réseau dans lequel pour établir un appel vers un point d'extrémité appelé, un point d'extrémité appelant émet, un message d'établissement d'appel comprenant un élément d'information de source et un élément d'information de destination ayant chacun une valeur de signalisation qui identifie respectivement le point d'extrémité appelant et le point d'extrémité appelé. Le procédé est remarquable en ce que le réseau établit ledit appel à condition que les dites valeurs de signalisation correspondent à des valeurs d'admission préalablement portées à la connaissance du réseau.
Particulièrement, ladite connaissance est comprise dans un jeton dont le réseau vérifie qu'une première valeur transmise dans le message d'établissement d'appel correspond à une deuxième valeur de jeton donnée par une équation qui comprend les dites valeurs de signalisation d'élément d'information de source et d'élément d'information de destination et un élément d'information aléatoire généré par le réseau pour être associé secrètement dans le réseau à la première valeur de jeton.
Avantageusement dans un réseau de type H.323, la première valeur de jeton est calculée par un groupe fonctionnel dit d'enregistrement, admission et statut au sein du réseau côté appelant au moyen de ladite équation lorsque ledit groupe fonctionnel reçoit un message de requête d'admission en provenance d'un point d'extrémité émetteur, ledit message de requête contenant un élément d'information de destination et un élément d'information de source identifiant ledit point d'extrémité émetteur. Ledit groupe fonctionnel envoie alors vers le point d'extrémité émetteur un message de confirmation d'admission contenant ladite première valeur de jeton.
Plus particulièrement en mode routé, un groupe fonctionnel dit de signalisation d'appel au sein du réseau reçoit le message d'établissement d'appel, vérifie que le message d'établissement contient la première valeur de jeton et recherche l'élément d'information aléatoire associé à ladite première valeur de jeton, et en cas de succès, calcule la deuxième valeur de jeton au moyen de ladite équation de façon à vérifier que ladite première valeur de jeton est égale à ladite deuxième valeur de jeton.
Plus particulièrement en mode direct, un groupe fonctionnel dit d'enregistrement, admission et statut au sein du réseau côté appelé, reçoit un message de requête d'admission en provenance du point d'extrémité appelé, ledit message de requête d'admission comprenant un élément d'information de source et un élément d'information de destination identifiant le point d'extrémité appelé, vérifie que le message de requête d'admission contient la première valeur de jeton et recherche l'élément d'information aléatoire associé à ladite première valeur de jeton, et en cas de succès, calcule la deuxième valeur de jeton au moyen de ladite équation de façon à envoyer un message de confirmation d'admission au point d'extrémité appelé à condition que ladite première valeur de jeton soit égale à ladite deuxième valeur de jeton.
Lorsqu'une vérification positive de correspondance entre la première et la deuxième valeur de jeton a pour effet de détruire une association entre élément d'information aléatoire et première valeur de jeton, on s'assure que le jeton ne sera pas réutilisé pour une tentative frauduleuse.
Un deuxième objet de l'invention est un élément de contrôle d'un réseau dans lequel pour établir un appel vers un point d'extrémité appelé, un point d'extrémité appelant émet, un message d'établissement d'appel comprenant un élément d'information de source et un élément d'information de destination ayant chacun une valeur de signalisation qui identifie respectivement le point d'extrémité appelant et le point d'extrémité appelé. L'élément de contrôle est remarquable en ce qu'il comprend des moyens pour établir ledit appel à condition que les dites valeurs de signalisation correspondent à des valeurs d'admission préalablement portées à la connaissance du réseau. Particulièrement l'élément de contrôle comprend des moyens pour vérifier qu'une première valeur de jeton transmise dans le message d'établissement d'appel correspond à une deuxième valeur de jeton donnée par une équation qui comprend les dites valeurs de signalisation d'élément d'information de source et d'élément d'information de destination et un élément d'information aléatoire généré par le réseau pour être associé secrètement dans le réseau à la première valeur de jeton.
Un élément de contrôle de type H.323 comprend avantageusement un groupe fonctionnel dit d'enregistrement, admission et statut agencé pour recevoir un message de requête d'admission en provenance d'un point d'extrémité émetteur, pour extraire dudit message de requête un élément d'information de destination et un élément d'information de source identifiant ledit point d'extrémité émetteur, pour calculer ladite première valeur de jeton au moyen de ladite équation, et pour envoyer vers le point d'extrémité émetteur un message de confirmation d'admission contenant ladite première valeur de jeton.
Plus particulièrement pour mettre en œuvre le mode routé, le même élément de contrôle ou un autre élément de contrôle comprend un groupe fonctionnel dit de signalisation d'appel agencé pour recevoir le message d'établissement d'appel, pour vérifier que le message d'établissement contient la première valeur de jeton et rechercher l'élément d'information aléatoire associé à ladite première valeur de jeton, pour calculer en cas de succès la deuxième valeur de jeton au moyen de ladite équation, et pour vérifier que ladite première valeur de jeton est égale à ladite deuxième valeur de jeton.
Plus particulièrement pour mettre en œuvre le mode direct, l'un des éléments de contrôle précédents ou encore un autre élément de contrôle comprend un groupe fonctionnel dit d'enregistrement, admission et statut agencé pour recevoir un message de requête d'admission en provenance du point d'extrémité appelé, ledit message de requête d'admission comprenant un élément d'information de source et un élément d'information de destination identifiant le point d'extrémité appelé, pour vérifier que le message de requête d'admission contient la première valeur de jeton et rechercher l'élément d'information aléatoire associé à ladite première valeur de jeton, pour calculer en cas de succès la deuxième valeur de jeton au moyen de ladite équation, et pour envoyer un message de confirmation d'admission au point d'extrémité appelé à condition que ladite première valeur de jeton soit égale à ladite deuxième valeur de jeton.
En étant agencé pour détruire une association entre élément d'information aléatoire et première valeur de jeton après vérification positive de correspondance entre la première et la deuxième valeur de jeton, un élément de contrôle s'oppose à une utilisation multiple d'une même première valeur de jeton.
D'autres détails et avantages de l'invention ressortent de la description d'un mode de mise en œuvre qui suit en référence aux dessins annexés dans lesquels:
- La figure 1 présente un schéma d'établissement d'appel en mode routé;
- La figure 2 présente un schéma d'établissement d'appel en mode direct; - Les figures 3 à 5 illustrent différentes architectures organiques de traitement des messages d'établissement d'appel;
- La figure 6 présente un schéma de principe de mise en œuvre de procédé conforme à l'invention en mode routé;
- La figure 7 présente un schéma de principe de mise en œuvre de procédé conforme à l'invention en mode direct;
- Les figures 8 à 15 présentent des exemples d'établissement d'appel détectés valides grâce au procédé selon l'invention;
- Les figures 16 à 19 présentent des exemples d'établissement d'appel détectés frauduleux grâce au procédé selon l'invention.
En préliminaire, on rappelle la sémantique de différents champs de messages utiles pour une meilleure compréhension de l'invention, tels qu'ils sont désignés par leurs étiquettes acronymes dans les recommandations H.323 et H.225. Les champs du message ARQ auxquels se réfère le procédé, ainsi que leur notation et leur statut normalisés sont les suivants :
• adresse source (ASA) : adresse d'émission du message ARQ, au sens adresse de transport réseau. Le format de ce paramètre ne dépend que du réseau paquet utilisé pour l'interconnexion des entités H.323 et est indépendant de l'invention. Statut de ce champ : obligatoire
• srclnfo (SIA) : un ou plusieurs alias désignant le point d'extrémité appelant. Ces alias peuvent être un numéro de téléphone, un identifiant e164, un identifiant H.323, une adresse e-mail ou autre. Le type d'alias utilisé n'a pas d'impact sur le procédé décrit. Statut de ce champ : obligatoire
• srcCallSignalAddress (SCA) : adresse de transport réseau pour le canal CS (CaII Signalling) du point d'extrémité appelant. Statut de ce champ : optionnel
• destinationlnfo (DIA) : un ou plusieurs alias désignant le point d'extrémité appelé, selon le même format que le champ SIA. Statut de ce champ : optionnel si DCA présent
• destCallSignalAddress (DCA) : adresse de transport réseau pour le canal CS (CaII Signalling) du point d'extrémité appelé. Statut de ce champ : optionnel si DIA présent
Les champs du message Setup auxquels se réfère le procédé, ainsi que leur notation et leur statut normalisés sont les suivants :
• adresse source (ASS) : pendant du champ ASA pour le message Setup. Statut de ce champ : obligatoire
• sourceAddress (SAS) : pendant du champ SIA pour le message Setup. Statut de ce champ : optionnel si SCS présent
• srcCallSignalAddress (SCS) : pendant du champ SCA pour le message Setup. Statut de ce champ : optionnel si SAS présent • destinationAddress (DAS) : pendant du champ DIA pour le message Setup. Statut de ce champ : optionnel si DCS présent
• destCallSignalAddress (DCS) : pendant du champ DCA pour le message Setup. Statut de ce champ : optionnel si DAS présent On indique que le message Setup comporte aussi dans son en-tête, deux champs optionnels : Called Party Number et Calling Party Number qui reprennent les informations des champs SAS et DAS.
De façon à vérifier la corrélation, en entrée du réseau H.323, entre un message Setup émis par un point d'extrémité et un message d'admission ARQ préalablement émis par ce même point d'extrémité, un procédé conforme à l'invention met en oeuvre un mécanisme de jeton incorporant certaines informations des messages ARQ et Setup qui sont sensibles du point de vue de la sécurité.
Le schéma de principe présenté en figure 6, permet de décrire de façon détaillée le mécanisme de jeton en mode GKR tel que nous le connaissons en référence à la figure 1. Lorsque la fonction RAS reçoit un message de requête ARQ 1 ) dans l'équipement réseau côté appelant, la fonction RAS y vérifie en premier lieu si cette requête est acceptable ou pas. Cette vérification est basée sur les principes des Recommandations H.323 et H.225 pour l'admission d'appel et avantageusement sur des règles de cohérence additionnelles pour les messages ARQ telles que celles définies dans la demande de brevet FR 05 02110. Si la vérification est positive, la fonction RAS côté appelant génère un jeton J, sur la base d'un élément dit A d'information aléatoire, d'un élément dit IS d'information de source et d'un élément dit ID d'information de destination. Les éléments IS et ID sont dérivées du message ARQ. Dans l'étape 2), la fonction RAS côté appelant transfère les éléments A et J vers la première fonction CS résidant dans l'équipement réseau en charge de recevoir ultérieurement le message Setup. Dans l'étape 3), la fonction RAS côté appelant retourne un message ACF contenant le jeton J vers le point d'extrémité appelant qui, dans l'étape 4), envoie un message Setup complété par le jeton J. Dans le mode GKR, le message Setup est envoyé vers la première fonction CS qui est en charge de router l'appel. Selon la Recommandation H.323, l'adresse de transport vers laquelle doit être envoyé le message Setup est déterminée par les éléments réseaux et indiquée au terminal appelant dans le contenu du message ACF. Dans le mode GKR, la validité du message Setup par rapport au jeton J est vérifiée par la première fonction CS.
Le schéma de principe présenté en figure 7, permet de décrire de façon détaillée le mécanisme de jeton en mode DIR tel que nous le connaissons en référence à la figure 2. Lorsque la fonction RAS reçoit un message de requête ARQ 1 ) dans l'équipement réseau côté appelant, la fonction RAS y vérifie en premier lieu si cette requête est acceptable ou pas de façon semblable à celle du mode GKR. Dans l'étape 2), la fonction RAS côté appelant transfère les éléments A et J vers la fonction RAS résidant dans l'équipement réseau côté appelé. Dans l'étape 3), la fonction RAS côté appelant retourne un message ACF contenant le jeton J vers le point d'extrémité appelant qui, dans une étape 4), envoie un message Setup complété par le jeton J. Dans le mode DIR le message Setup est envoyé directement vers le terminal appelé. Selon la Recommandation H.323, l'adresse de transport vers laquelle doit être envoyé le message Setup, est déterminée par les éléments réseaux et indiquée au terminal appelant dans le contenu du message ACF. Dans le mode DIR, le point d'extrémité appelé envoie un message ARQ 7) basé sur les informations du message Setup et contenant le jeton J, vers l'équipement réseau côté appelé. Le message ARQ fait l'objet d'une vérification par la fonction RAS côté appelé qui génère un message de confirmation ACF 8) pour accepter l'appel si la vérification est positive.
L'élément d'information A est un nombre aléatoire qui peut être de nature numérique ou alpha numérique et de longueur quelconque. Cet élément s'applique à un et un seul jeton, aussi est-il généré aléatoirement à chaque nouveau calcul de jeton.
Une valeur dite d'établissement de l'élément d'information IS est déterminée à partir du message ARQ reçu par la fonction RAS côté appelant et est régie par l'équation :
IS = SIA + ASA + SCA où le signe '+' désigne l'opérateur de concaténation, et les sigles SIA, ASA et SCA sont ceux précédemment définis. Les champs ASA et SCA font référence uniquement à l'adresse réseau et non au port associé. Si le champ SCA n'est pas inclus dans le message ARQ, il prend la valeur vide dans l'équation précédente.
Une valeur de l'élément d'information ID, dite d'établissement, est déterminée à partir du message ARQ reçu par la fonction RAS côté appelant et est régie par l'équation :
ID = DIA + DCA où le signe '+' désigne l'opérateur de concaténation, et les sigles DIA et DCA sont ceux précédemment définis. Le champ DCA fait référence uniquement à l'adresse réseau et non au port associé. Les champs DIA et DCA étant mutuellement optionnels, si l'un d'eux n'est pas inclus dans le message ARQ, il prend la valeur vide dans l'équation précédente.
Le jeton J est généré par la fonction RAS côté appelant et sa valeur est régie par l'équation :
J = hash (A + IS + ID) où '+' est l'opérateur de concaténation et 'hash' une fonction de hachage, comme par exemple l'algorithme connu MD5, qui retourne une chaîne de caractères de taille fixe. Alors que l'élément d'information A est aléatoire, les éléments IS et ID ne dépendent que de l'appel en cours.
Le jeton J et l'élément d'information A sont transférés par la fonction RAS côté appelant vers l'entité en charge de réaliser la fonction de vérification. Cette entité destinatrice peut être une fonction CS (mode "GKR") ou la fonction RAS côté appelé (mode "DIR"). On indique que la fonction RAS côté appelé peut coïncider avec la fonction RAS côté appelant dans le cas où les points d'extrémité appelant et appelé sont enregistrés auprès du même élément de contrôle et que l'établissement d'appel est direct (mode "DIR").
Deux principaux modes sont envisageables pour le transfert des informations A et J :
• Mode interne : les informations A et J sont transférées via une mémoire ou un bus de communication interne à l'équipement. Ce procédé n'est possible que pour les architectures de type Al et de plus lorsque les points d'extrémité appelant et appelé sont enregistrés sur le même élément de contrôle
• Mode par message : les informations A et J sont transférées via un message de signalisation de type H.323 ou propriétaire.
Avantageusement, le message LRQ sera choisi, car il est utilisé nominalement entre les entités H.323 pour localiser le point d'extrémité appelé et déterminer l'adresse de transport vers laquelle doit être envoyé le message Setup. Le mode par message peut s'appliquer à tous les cas de mise en œuvre.
L'entité recevant les informations A et J est responsable de les stocker dans une base de jetons puis de supprimer l'enregistrement correspondant lorsque l'une des deux règles suivantes est vérifiée : • Utilisation : les informations A et J ont été extraites de la base pour servir de vérification, suite à la réception d'un message Setup ou ARQ portant un jeton de même valeur que J. Cette règle s'applique si le résultat de la vérification est positif. Il est préférable de ne pas détruire le jeton en cas de vérification négative de façon à ne pas empêcher un point d'extrémité autorisé de faire usage du jeton;
• Expiration : les informations A et J n'ont pas été utilisées au bout d'un temps de stockage défini par l'opérateur. Ce temps de stockage est typiquement égal à la durée maximale admissible entre la réception du message ARQ et la réception du message Setup associé. La première condition sert typiquement à éviter les attaques de type rejeu en garantissant qu'un jeton ne puisse servir qu'une et une seule fois, alors que la seconde condition évite les attaques par saturation de ressources consistant à stocker "indéfiniment" un grand nombre de jetons dans le système.
Dans le mode GKR, la fonction CS de l'entité réseau qui reçoit le message Setup émis par le point d'extrémité appelant, extrait de ce message le jeton J et cherche une correspondance avec un jeton de même valeur enregistré dans sa base de jetons. Si une correspondance est trouvée, l'entité récupère l'élément d'information A associé à ce jeton dans la base, sinon le jeton est considéré comme non valide et l'appel est rejeté.
Une valeur d'élément d'information de source ISR et une valeur d'élément d'information de destination IDR, dites valeurs de signalisation, sont déterminées à partir du message d'établissement d'appel Setup.
Après avoir récupéré l'élément d'information A, la fonction CS calcule un nouveau jeton JR selon l'équation : (JR) = hash (A + ISR + IDR)OÙ :
• '+' est l'opérateur de concaténation;
• 'hash' est la même fonction de hachage que celle utilisée côté appelant;
• ISR = ASS + SAS + SCS (selon les définitions précédentes)
• IDR = DAS + DCS (selon les définitions précédentes)
Si le jeton JR est égal au jeton J, alors l'établissement d'appel peut se poursuivre, sinon le message Setup est considéré non valide et l'appel est rejeté.
Remarques : • Les champs ASS, SCS et DCS font référence uniquement aux adresses réseau et non aux ports associés
• les champs renseignés par le point d'extrémité appelant doivent être homogènes entre les messages ARQ et Setup. Ainsi, SAS doit apparaître dans le message Setup puisque SIA est obligatoire dans le message ARQ, les champs SCS et SCA doivent être simultanément absents ou présents, de même pour les couples de champs (DAS, DIA) et (DCS, DCA),
• les champs d'adresses de transport ou d'identifiant d'appelé ou d'appelant doivent avoir le même format entre les messages ARQ et Setup. Ce point est également de la responsabilité du point d'extrémité appelant, • si l'en-tête du message Setup inclut les champs [Calling Party Number] et
[Called Party Number] ils pourront avantageusement être corrélés aux valeurs des champs SAS et DAS si présents. Dans le mode DIR, sur réception du message Setup, le point d'extrémité appelé envoie un message ARQ 7) vers l'entité RAS auprès de laquelle il est enregistré avec comme champs : • SIA = identifiant d'appelant contenu dans le message Setup
• SCA = adresse source du message Setup
• DIA = son propre identifiant d'appel
• DCA = sa propre adresse de transport pour le canal CS
• J = la valeur de jeton contenue dans le message Setup
Sur réception du message ARQ 7), la fonction RAS côté appelé cherche une correspondance entre le jeton J reçu et un jeton de même valeur enregistré dans sa base.
Une valeur d'élément d'information de source ISR et une valeur d'élément d'information de destination IDR, dites valeurs de signalisation, sont déterminées à partir du message ARQ 7).
Lorsqu'elle est trouvée, la correspondance permet à la fonction RAS d'extraire la valeur A associée au jeton dans la base de façon à calculer un nouveau jeton JR selon l'équation :
JR = hash (A + ISR + IDR) où :
• '+' est l'opérateur de concaténation
• 'hash' est la même fonction de hachage que celle utilisée côté appelant • ISR = SIA + SCA (avec SIA et SCA tels que définis ci-dessus)
• IDR = DIA + DCA (avec DIA et DCA tels que définis ci-dessus)
Si le jeton JR est égal au jeton J, alors l'établissement d'appel peut se poursuivre et un message ACF 8) est envoyé vers l'appelé, sinon l'établissement d'appel échoue et un message ARJ est envoyé vers l'appelé.
Remarques : • Les champs SCA et DCA font référence uniquement aux adresses réseau et non aux ports associés,
• les champs envoyés par l'appelé dans le message ARQ 7) doivent être similaires et du même format que ceux envoyés par l'appelant dans le message ARQ 1). Ainsi, le champ DIA doit être simultanément présent ou simultanément absent dans ces deux messages, de même que le champ DCA,
• pour que l'élément d'information ISR puisse être égal à IS, il est obligatoire que l'appelant ne renseigne pas le champ SCA dans le message ARQ 1 ) qu'il envoie dans le mode d'appel "DIR".
Le mécanisme décrit dans les paragraphes précédents consiste, à partir d'une demande ARQ valide, à communiquer vers la fonction CS correspondante des éléments d'identification d'appel IS et ID lui permettant de valider le message Setup attendu.
Plutôt que d'utiliser un principe de jeton qui donne une signature des éléments IS, ID et d'un élément aléatoire A, un mécanisme alternatif consiste à transférer directement les informations IS et ID vers la fonction CS supposée recevoir le message Setup. Dans ce cas, le transfert du jeton J dans les messages ACF 3), Setup 4) et ARQ 7) n'est plus nécessaire.
Néanmoins, cette alternative présente l'inconvénient de devoir, pour tout message Setup 4) reçu, recalculer les éléments ISR et IDR avant toute recherche de ce couple dans la base d'appels en instances. Cela se traduit par une consommation accrue de ressources dans la fonction CS réceptrice, et des possibilités d'attaques DOS (Deny Of Service) par saturation de ressources. A l'inverse, le jeton J offre un moyen d'indexation efficace, de nature à réduire ce genre d'attaques.
Le mécanisme décrit dans les paragraphes précédents peut aisément être transposé à la vérification de messages Setup envoyés entre éléments de contrôles dans le cas d'un établissement d'appel inter domaines. De façon schématique, l'élément de contrôle qui envoie le message Setup, calcule un jeton J associé à ce Setup et transfère les informations A, J vers l'élément de contrôle supposé recevoir le Setup. Comme précédemment, le transfert de ces informations peut se faire via un mécanisme propriétaire ou avantageusement en utilisant un message de signalisation H.323 tel que le message LRQ. L'élément de contrôle recevant le Setup extrait l'information J qu'il contient, et si le jeton J est présent dans sa base de jetons, il procède à la vérification, tel que décrit précédemment pour savoir s'il peut accepter le message Setup.
Les exemples suivants illustrent des tentatives d'établissement d'appels dans des cas valides en référence aux figures 8 à 15 et frauduleux en référence aux figures
16 à 19. Bien que non exhaustifs, ils brossent les cas les plus fréquents au niveau opérationnel. Ils se déclinent selon les architectures Al, AR et AF et les modes
"GKR" et "DIR". Seule la partie de dialogue relative au procédé de vérification est décrite, ainsi que les valeurs des éléments de messages correspondants. Par simplification, on suppose dans tous les exemples que l'élément d'information A est fixe et égal à '9090'.
La figure 8 présente un appel valide en mode GKR dans une architecture Al où les points d'extrémités sont sur le même GK. Détails :
- I ) ARQ : ASA='1.1.1.10\ SIA=1123', SCA=1LI .1.101, DIA=1134', DCA="
- calcul: J= hash (A+SIA+ASA+SCA+DIA+DCA) = hash ('9090'+'123'+11.1.1.10'+'1.1.1.10'+'134') - 3) ACF : [destCallSignalAddress]='1.1.1.1', J - 4) Setup : ASS=1LLLIO1, SAS=1123', SCS=1LLLIO1, DAS=1134', DCS=", J
- vérification que J est enregistré et récupération de la valeur A
- calcul: JR= hash (A+SAS+ASS+SCS+DAS+DCS) = hash ('9090'+'123'+11.1.1.10'+'1.1.1.10'+'134')
- vérification JR = J donc envoi du Setup 6) vers l'appelé
La figure 9 présente un appel valide en mode DIR dans une architecture Al où les points d'extrémités sont sur le même GK. Détails : - 1 ) ARQ : ASA='1.1.1.10', SIA=1123', SCA=", DIA='134\ DCA="
- calcul: J= hash (A+SIA+ASA+SCA+DIA+DCA) = hash ('9090'+'i23'+'i .i .i .i0'+'i34')
- 3) ACF : [destCallSignalAddress]='1.1.1.15', J - 4) Setup : ASS='1.1.1.10\ SAS='123', SCS='1.1.1.10', DAS=1134', DCS=", J
- 7) ARQ : ASA=1H .1.15', SIA=1123', SCA=1LI .1.101, DIA=1134', DCA=", J
- vérification que J est enregistré et récupération de la valeur A
- calcul: JR= hash (A+SIA+SCA+DIA+DCA) = hash (190901+1i231+1i .i .Li01+1i341) - vérification JR = J donc 8) envoi du ACF vers l'appelé On notera que :
- dans le mode "DIR", le message ARQ 1) ne doit pas contenir de paramètre SCA afin que les deux jetons puissent être comparés;
- qu'il soit renseigné ou pas, le champ SCS du message Setup 4) n'est pas reporté dans le message ARQ 7), toutefois il est important de corréler sa valeur à l'adresse source du message Setup;
- dans ce deuxième exemple, l'appelant n'utilisant pas le champ DCA du message ARQ, l'appelé ne doit également pas l'utiliser afin que la comparaison des jetons ait un sens.
La figure 10 présente un appel valide en mode GKR dans une architecture Al où les points d'extrémités sont sur deux GK distincts. Détails :
- I ) ARQ : ASA=1L 1.1.10', SIA='123\ SCA=1LLLIO1, DIA='340\ DCA=" - calcul: J= hash (A+SIA+ASA+SCA+DIA+DCA) = hash ('9090'+'123'+11.1.1.10'+11.1.1.10'+'34O1) - 3) ACF : [destCallSignalAddress]='L 1.1.1', (J) - 4) Setup : ASS=1LLLIO1, SAS=1123', SCS=1LLLIO1, DAS='340\ DCS=", J
- vérification par GK1 que J est enregistré et récupération de la valeur A - calcul par GK1 de JR = hash (A+SAS+ASS+SCS+DAS+DCS) = hash ('9090'+'123'+11.1.1.10'+'1.1.1.10'+'34O1)
- vérification que JR = J donc envoi du Setup 5) vers GK2 On notera que GK1 peut éventuellement initier un échange 2) LRQ/LCF avec GK2 pour localiser le point d'extrémité appelé.
La figure 11 présente un appel valide en mode GKR dans une architecture Al où les points d'extrémités sont sur deux éléments de contrôle distincts et où l'élément de contrôle côté appelant GK1 décide de ne pas router l'appel. Détails :
- I ) ARQ : ASA=1L 1.1.10', SIA=1123', SCA=", DIA='34O', DCA="
- calcul par GK1 : J=hash (A+SIA+ASA+SCA+DIA+DCA) = hash ('9090'+'123'+'1.1.1.10'+'34O1)
- 2) LRQ : [destinationlnfo]='340\ (A, J)
- 2) LCF : [callSignalAddress]='1.1.3.1'
- 3) ACF : [destCallSignalAddress]='1.1.3.1', (J)
- 4) Setup : ASS='1.1.1.10', SAS='123', SCS=", DAS='34O', DCS=", (J) - vérification par GK2 que (J) est enregistré et récupération de la valeur (A)
- calcul par GK2: JR = hash (A+SAS+ASS+SCS+DAS+DCS) = hash ('9090'+'123'+'1.1.1.10'+'34O1)
- vérification par GK2 que JR = J donc envoi du Setup 6) vers l'appelé. On notera que : - l'envoi du message LRQ est nécessaire car le numéro "340" n'est pas enregistré sur GK1 et ce message permet de véhiculer les informations A et J. Tout autre message remplissant la même fonction est acceptable;
- dans le message LCF, GK2 donne sa propre adresse car il décide de router l'appel; - comme au moins un des éléments de contrôle GK1 ou GK2 a décidé de router l'appel, le mode résultant est "GKR", bien que GK1 soit en mode direct.
La figure 12 présente un appel valide en mode DIR dans une architecture Al où les points d'extrémités sont sur deux éléments de contrôle distincts. Détails :
- I ) ARQ : ASA=1L 1.1.10', SIA=1123', SCA=", DIA='34O', DCA="
- calcul par GKL J=hash (A+SIA+ASA+SCA+DIA+DCA) =
118511 ('9090'+'123'+'1.1.1.10'+'34O1) - 2) LRQ : [destinationlnfo]='340', (A, J)
- 2) LCF : [callSignalAddress]='1.1.3.201
- 3) ACF : [destCallSignalAddress]='1.1.3.20', (J)
- 4) Setup : ASS='1.1.1.10', SAS='123\ SCS=", DAS='34O', DCS=", (J) - 7) ARQ : ASA='1.1.3.20', SIA=1123', SCA=1L 1.1.10', DIA='340\ DCA=", (J)
- vérification par GK2 que J est enregistré et récupération de la valeur A;
- calcul par GK2: JR = hash (A+SIA+SCA+DIA+DCA) = hash ('9090'+'123'-1-'1.1.1.10'+'34O1)
- vérification JR = J donc envoi du ACF 8) vers l'appelé. On notera que :
- en mode "DIR", le paramètre SCA de l'ARQ appelant ne doit pas être renseigné;
- comme le paramètre DCA n'est pas renseigné dans l'ARQ appelant, il ne doit pas être non plus renseigné dans l'ARQ appelé.
La figure 13 présente un appel valide en mode GKR dans une architecture AR où les points d'extrémités sont sur un même élément de contrôle avec répartition des fonctions RAS et CS respectivement sur un équipement Equip.1 et sur un équipement Equip.2. Détails : - I ) ARQ : ASA=1L 1.1.10', SIA=1123', SCA=1LLLIO1, DIA=1134', DCA="
- calcul par Equip.1 : J= hash (A+SIA+ASA+SCA+DIA+DCA) = hash ('9090'+'123'+11.1.1.1O'+'1.1.1.10'+'134')
- 2) LRQ : [destinationlnfo]='134\ (A, J)
- 2) LCF : [callSignalAddress]='1.1.1.2' - 3) ACF : [destCallSignalAddress]='1.1.1.2', J
- 4) Setup : ASS=1LLLIO1, SAS=1123', SCS=1LLLIO1, DAS=1134', DCS=", (J)
- vérification par l'équipement Equip.2 que J est enregistré et récupération de la valeur A;
- calcul par Equip.2: JR= hash (A+SAS+ASS+SCS+DAS+DCS) = hash ('9090'+'123'+'1.1.1.10'+'1.1.1.10'+'134')
- vérification JR = J donc envoi du Setup 6) vers l'appelé On notera que si le point d'extrémité appelé n'est pas enregistré sur le même GK que l'appelant, l'équipement Equip.2 relaie l'appel vers l'entité suivante, ce qui revient à modifier la destination du message Setup.
La figure 14 présente un appel valide en mode GKR dans une architecture AR où les points d'extrémités sont sur un même élément de contrôle avec répartition des fonctions RAS et CS respectivement sur un équipement Equip.1 et sur un équipement Equip.2. La variante consiste en ce que l'équipement 1 réalise des préfonctions CS, en particulier la vérification du jeton et le relais du message Setup qui n'est plus envoyé directement vers l'équipement 2. Détails :
- I ) ARQ : ASA='1.1.1.10\ SIA='123\ SCA=11.1.1.10', DIA='134', DCA=11.1.1.1'
- calcul par Equip.1 : J= hash (A+SIA+ASA+SCA+DIA+DCA) = hash ('9090'+'123'+11.1.1.10'+11.1.1.10'+'134'+11.1.1.1') - 3) ACF : [destCallSignalAddress]='1.1.1.1', (J)
- 4) Setup : ASS=11.1.1.10', SAS='123', SCS=11.1.1.10', DAS='134', DCS=11.1.1.1', J
- vérification par l'équipement Equip.1 que J est enregistré et récupération de la valeur A;
- calcul JR= hash (A+SAS+ASS+SCS+DAS+DCS) = hash ('9090'+'123'+'1.1.1.10'+'1.1.1.10'+'134'+'1.1.1.1')
- vérification JR = J donc passage à l'étape suivante
- 5) Setup : ASS=11.1.1.1', SAS='123', SCS=11.1.1.1', DAS='134', DCS=11.1.1.2'
- l'équipement Equip.2 vérifie la localisation du destinataire et lui envoie le message Setup 6) On notera que :
- l'envoi du message ACF 3) par l'équipement 1 peut être précédé d'une phase LRQ/LCF durant laquelle l'équipement 1 vérifie que l'équipement 2 est prêt à recevoir le message Setup;
- contrairement à l'exemple de la figure 13, la vérification du jeton est ici réalisée par l'équipement 1 , et non par l'équipement 2, ce qui explique que le message Setup 5) ne contient pas le jeton J; - la phase 6) d'envoi du message Setup est normalement prolongée par un échange ARQ/ACF entre EP2 et l'équipement 1 (phase non représentée ici car n'entrant pas en compte dans le procédé);
- si le terminal appelé n'est pas localisé dans la même zone que l'équipement 1 , le prolongement de l'établissement d'appel est de la responsabilité de l'équipement 2.
La figure 15 présente un appel valide en mode GKR dans une architecture AF où les points d'extrémités sont enregistrés sur un même élément de contrôle avec un équipement frontal Equip.1 et répartition des fonctions RAS et CS respectivement sur un équipement Equip.2 et sur un équipement Equip.3. Détails :
- I ) ARQ : ASA=1L 1.1.10', SIA='123\ SCA='1.1.1.10\ DIA='134\ DCA='1.1.1.1'
- 1 bis) ARQ : ASA=1H .1.1', SIA=1123', SCA=1LLLI1, DIA=1134', DCA="
- calcul par Equip.2: J= hash (A+SIA+ASA+SCA+DIA+DCA) = hash ('9090'+'123'+'1.1.1.1 '+'1.1.1.1'+'1341J
- 2) LRQ : [destinationlnfo]='134\ (A, J)
- 2) LCF : [callSignalAddress]='1.1.1.3'
- 3) ACF : [destCallSignalAddress]='1.1.1.3', (J) - 3bis) ACF : [destCallSignalAddress]='L 1.1.1', (J) - 4) Setup : ASS=1LLLIO1, SAS='123', SCS=1LLLIO1, DAS='134', DCS=1LLLI1,
(J)
- 5) Setup : ASS=1L 1.1.1', SAS=1123', SCS=1LLLI1, DAS=1134', DCS=", (J)
- vérification par l'équipement 3 que J est enregistré et récupération de la valeur (A)
- calcul par Equip.3: JR= hash (A+SAS+ASS+SCS+DAS+DCS) = hash ('9090'+'i23'+'LLi .r+'i .Li .r+'i34')
- vérification JR = J donc envoi du message Setup 6) vers le terminal appelé. On notera que :
- la phase 6 est normalement prolongée par un échange ARQ/ACF entre EP2 et l'équipement 2 (phase non représentée ici car n'entrant pas en compte dans le procédé);
- si le terminal appelé n'est pas localisé dans la même zone que l'équipement 1 , le prolongement de l'établissement d'appel est de la responsabilité de l'équipement 3, mais cela ne change en rien le principe de la vérification. La figure 16 présente un appel frauduleux en mode GKR dans une architecture Al avec tentative d'usurpation d'identité par un client régulier.
Dans un souci de simplification, toutes les tentatives d'appels frauduleux présentées s'appliquent à l'architecture Al, mais ces principes sont aisément transposables aux architectures AR et AF. Détails :
- I ) ARQ : ASA='1.1.1.10\ SIA=1123', SCA=11.1.1.101, DIA=1134', DCA=" - calcul: J= hash (A+SIA+ASA+SCA+DIA+DCA) = hash ('9090'+'123'+11.1.1.1O'+'1.1.1.10'+'134') - 3) ACF : [destCallSignalAddress]='1.1.1.1', (J) - 4) Setup : ASS='1.1.1.10', SAS='145', SCS=1LI .1.101, DAS=1134', DCS=", J
- vérification par le GK que J est enregistré et récupération de la valeur A - calcul: JR= hash (A+SAS+ASS+SCS+DAS+DCS) = hash ('9090'+'145'+11.1.1.10'+11.1.1.10'+'134')
- comme la vérification JR = J échoue, l'appel est rejeté.
La figure 17 présente un appel frauduleux en mode GKR dans une architecture Al avec tentative d'accès gratuit au service. Détails : - 4) Setup : ASA=11.1.1.16', SAS=1123', SCS=11.1.1.16', DAS=1134', DCS=", (J)
- vérification par le GK que J est enregistré dans sa base de jetons : échec -> l'appel est rejeté On notera que:
- un message Setup sans jeton aboutit également au rejet de l'appel par le GK;
- le numéro de téléphone appelant pouvant être positionné à n'importe quelle valeur, il peut ou pas coïncider avec un numéro déjà enregistré (usurpation d'identité);
- l'étape consistant à vérifier la présence du jeton dans la base étant très peu consommatrice de ressources, la probabilité d'une attaque DOS (Deny Of Service) par envoi d'un grand nombre de jetons reste faible. La figure 18 présente un appel frauduleux en mode GKR dans une architecture Al avec tentative d'accès gratuit au service. Cet exemple est basé sur une attaque de type "relais ARQ" où l'attaquant bénéficie de la complicité d'un "client corrompu", c'est à dire d'un abonné au service capable de lire les messages de signalisation H.323 qui lui sont retournés par le réseau et de communiquer certaines informations clés à un internaute non abonné. L'attaquant utilisera généralement un numéro d'appelant différent de celui du "client corrompu". Détails :
- 1 ) ARQ : ASA='1.1.1.10\ SIA=1123', SCA=", DIA='134', DCA=" - calcul par GK: J= hash (A+SIA+ASA+SCA+DIA+DCA) = hash ('9090'+'123'+11.1.1.10'+'134') - 3) ACF : [destCallSignalAddress]='1.1.1.1', J; - 4) Setup : ASS='1.1.1.16', SAS='145', SCS=", DAS='134', DCS=", J
- vérification par le GK que J est enregistré et récupération de la valeur A -> OK; - calcul par GK: JR=hash (A+SAS+ASS+SCS+DAS+DCS) = hash ('9090'+'145'+'1.1.1.16'+'134')
- comme la vérification JR = J échoue, l'appel est rejeté. On notera que :
- en plus de l'information de jeton J envoyée dans une étape 10), le "client corrompu" qui a reçu l'ACF peut également transférer d'autres informations relatives à l'appel telles que les identifiants [callldentifier], [conferencelD];
- dans le cas où l'attaquant utiliserait le même numéro appelant que le "client corrompu" et réaliserait de l'usurpation d'adresse source, la vérification de jeton conduirait quand même à un échec du fait que le paramètre SCS devrait être positionné pour pointer vers l'attaquant.
La figure 19 présente un appel frauduleux en mode GKR dans une architecture Al tentative d'accès gratuit au service. Cet exemple est basé sur le même principe que le précédent, mais dans le cas du mode d'établissement d'appel direct. Détails :
- 1 ) ARQ : ASA='1.1.1.10', SIA=1123', SCA=", DIA='134\ DCA="
- calcul (J)= hash (A+SIA+ASA+SCA+DIA+DCA) = hash ('9090'+'123'+11.1.1.10'+'134') - 3) ACF : [destCallSignalAddress]='1.1.1.15', (J)
- 4) Setup : ASS='1.1.1.16\ SAS='145', SCS=", DAS='134', DCS=", (J)
- 7) ARQ : ASS=1H .1.15', SIA='145', SCA='1.1.1.16', DIA='134\ DCA=", (J)
- vérification par le GK que (J) est enregistré et récupération de la valeur (A) -> OK
- calcul (JR)= hash (A+SIA+SCA+DIA+DCA) = hash ('9090'+'145'+11.1.1.16'+'134')
- comme la vérification (JR) = (J) échoue, l'appel est rejeté.

Claims

Revendications:
1. Procédé de sécurisation d'un réseau dans lequel pour établir un appel vers un point d'extrémité appelé, un point d'extrémité appelant émet (4) un message d'établissement d'appel comprenant un élément d'information de source et un élément d'information de destination ayant chacun une valeur de signalisation qui identifie respectivement le point d'extrémité appelant et le point d'extrémité appelé, caractérisé en ce que le réseau établit ledit appel à condition que les dites valeurs de signalisation correspondent à des valeurs d'admission préalablement portées à la connaissance du réseau.
2. Procédé de sécurisation selon la revendication 1 , caractérisé en ce que ladite connaissance est comprise dans un jeton dont le réseau vérifie qu'une première valeur transmise dans le message d'établissement d'appel correspond à une deuxième valeur de jeton donnée par une équation qui comprend les dites valeurs de signalisation d'élément d'information de source et d'élément d'information de destination et un élément d'information aléatoire généré par le réseau pour être associé secrètement dans le réseau à la première valeur de jeton.
3. Procédé de sécurisation selon la revendication 2, caractérisé en ce que ladite première valeur de jeton est calculée par un groupe fonctionnel dit d'enregistrement, admission et statut au sein du réseau côté appelant au moyen de ladite équation lorsque ledit groupe fonctionnel reçoit (1 ) un message de requête d'admission en provenance d'un point d'extrémité requérant, ledit message de requête contenant un élément d'information de source identifiant ledit point d'extrémité requérant et un élément d'information de destination, et en ce que ledit groupe fonctionnel envoie (3) vers le point d'extrémité requérant un message de confirmation d'admission contenant ladite première valeur de jeton.
4. Procédé de sécurisation selon l'une des revendications 2 ou 3, caractérisé en ce qu'un groupe fonctionnel dit de signalisation d'appel au sein du réseau: - reçoit (4) le message d'établissement d'appel, - vérifie que le message d'établissement contient la première valeur de jeton et recherche l'élément d'information aléatoire associé à ladite première valeur de jeton, et en cas de succès:
- calcule la deuxième valeur de jeton au moyen de ladite équation, et - vérifie que ladite première valeur de jeton est égale à ladite deuxième valeur de jeton.
5. Procédé de sécurisation selon l'une des revendications 2 ou 3, caractérisé en ce qu'un groupe fonctionnel dit d'enregistrement, admission et statut au sein du réseau côté appelé:
- reçoit (7) un message de requête d'admission en provenance du point d'extrémité appelé, ledit message de requête d'admission comprenant un élément d'information de source et un élément d'information de destination identifiant le point d'extrémité appelé, - vérifie que le message de requête d'admission contient la première valeur de jeton et recherche l'élément d'information aléatoire associé à ladite première valeur de jeton, et en cas de succès:
- calcule la deuxième valeur de jeton au moyen de ladite équation, et
- envoie (8) un message de confirmation d'admission au point d'extrémité appelé à condition que ladite première valeur de jeton soit égale à ladite deuxième valeur de jeton.
6. Procédé de sécurisation selon l'une des revendications 2 à 5, caractérisé en ce qu'une vérification positive de correspondance entre la première et la deuxième valeur de jeton a pour effet de détruire une association entre élément d'information aléatoire et première valeur de jeton.
7. Procédé de sécurisation selon l'une des revendications 2 à 5, caractérisé en ce que ladite équation comprend une fonction de hachage appliquée à une concaténation de l'élément d'information de source, de l'élément d'information de destination et de l'élément d'information aléatoire.
8. Elément de contrôle (GK1 , GK2) d'un réseau dans lequel pour établir un appel vers un point d'extrémité appelé (EP2), un point d'extrémité appelant (EP1 ) émet (4) à destination du point d'extrémité appelé, un message d'établissement d'appel comprenant un élément d'information de source et un élément d'information de destination ayant chacun une valeur de signalisation qui identifie respectivement le point d'extrémité appelant et le point d'extrémité appelé, caractérisé en ce qu'il comprend des moyens pour établir ledit appel à condition que les dites valeurs de signalisation correspondent à des valeurs d'admission préalablement portées à la connaissance du réseau.
9. Elément de contrôle selon la revendication 8, caractérisé en ce qu'il comprend des moyens pour vérifier qu'une première valeur de jeton transmise dans le message d'établissement d'appel correspond à une deuxième valeur de jeton donnée par une équation qui comprend les dites valeurs de signalisation d'élément d'information de source et d'élément d'information de destination et un élément d'information aléatoire généré par le réseau pour être associé secrètement dans le réseau à la première valeur de jeton.
10. Elément de contrôle selon la revendication 9, caractérisé en ce qu'il comprend un groupe fonctionnel dit d'enregistrement, admission et statut (RAS) agencé pour recevoir un message de requête d'admission en provenance d'un point d'extrémité émetteur, pour extraire dudit message de requête un élément d'information de destination et un élément d'information de source identifiant ledit point d'extrémité émetteur, pour calculer ladite première valeur de jeton au moyen de ladite équation, et pour envoyer vers le point d'extrémité émetteur un message de confirmation d'admission contenant ladite première valeur de jeton.
11. Elément de contrôle selon l'une des revendications 9 ou 10, caractérisé en ce qu'il comprend un groupe fonctionnel dit de signalisation d'appel (CS) agencé pour recevoir le message d'établissement d'appel, pour vérifier que le message d'établissement contient la première valeur de jeton et rechercher l'élément d'information aléatoire associé à ladite première valeur de jeton, pour calculer en cas de succès la deuxième valeur de jeton au moyen de ladite équation, et pour vérifier que ladite première valeur de jeton est égale à ladite deuxième valeur de jeton.
12. Elément de contrôle selon l'une des revendications 9 ou 10, caractérisé en ce qu'il comprend un groupe fonctionnel dit d'enregistrement, admission et statut agencé pour recevoir un message de requête d'admission en provenance du point d'extrémité appelé, ledit message de requête d'admission comprenant un élément d'information de source et un élément d'information de destination identifiant le point d'extrémité appelé, pour vérifier que le message de requête d'admission contient la première valeur de jeton et rechercher l'élément d'information aléatoire associé à ladite première valeur de jeton, pour calculer en cas de succès la deuxième valeur de jeton au moyen de ladite équation, et pour envoyer un message de confirmation d'admission au point d'extrémité appelé à condition que ladite première valeur de jeton soit égale à ladite deuxième valeur de jeton.
13. Elément de contrôle selon l'une des revendications 9 à 12, caractérisé en ce qu'il est agencé pour détruire une association entre élément d'information aléatoire et première valeur de jeton après vérification positive de correspondance entre la première et la deuxième valeur de jeton.
14. Elément de contrôle selon l'une des revendications 9 à 12, caractérisé en ce que ladite équation comprend une fonction de hachage appliquée à une concaténation de l'élément d'information de source, de l'élément d'information de destination et de l'élément d'information aléatoire.
EP06779007A 2005-07-12 2006-07-03 Mecanisme de protection des reseaux h.323 pour les fonctions d'etablissement d'appel Withdrawn EP1902564A2 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0552165 2005-07-12
PCT/FR2006/050666 WO2007006992A2 (fr) 2005-07-12 2006-07-03 Mecanisme de protection des reseaux h.323 pour les fonctions d'etablissement d'appel

Publications (1)

Publication Number Publication Date
EP1902564A2 true EP1902564A2 (fr) 2008-03-26

Family

ID=36117632

Family Applications (1)

Application Number Title Priority Date Filing Date
EP06779007A Withdrawn EP1902564A2 (fr) 2005-07-12 2006-07-03 Mecanisme de protection des reseaux h.323 pour les fonctions d'etablissement d'appel

Country Status (3)

Country Link
US (1) US8406223B2 (fr)
EP (1) EP1902564A2 (fr)
WO (1) WO2007006992A2 (fr)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8190753B2 (en) * 2006-08-28 2012-05-29 Samsung Electronics Co., Ltd. System and method for protecting emergency response services in telecommunication networks from attack
US9332119B1 (en) * 2013-03-07 2016-05-03 Serdar Artun Danis Systems and methods for call destination authenticaiton and call forwarding detection
US9060057B1 (en) * 2013-03-07 2015-06-16 Serdar Artun Danis Systems and methods for caller ID authentication, spoof detection and list based call handling
US9979818B2 (en) * 2013-08-06 2018-05-22 Verizon Patent And Licensing Inc. Caller ID verification
US20170104870A1 (en) * 2014-06-25 2017-04-13 Orange A method to authenticate calls in a telecommunication system
US10938982B1 (en) 2019-04-04 2021-03-02 Next Caller, Inc. Telecommunications validation system and method
US11595515B2 (en) * 2019-09-30 2023-02-28 Ringcentral, Inc. System and method of caller verification
CN111556501B (zh) * 2020-05-12 2023-04-18 微位（深圳）网络科技有限公司 一种可信通信系统及方法

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6324271B1 (en) * 1999-08-17 2001-11-27 Nortel Networks Limited System and method for authentication of caller identification

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2007006992A2 *

Also Published As

Publication number Publication date
WO2007006992A2 (fr) 2007-01-18
US8406223B2 (en) 2013-03-26
US20090080416A1 (en) 2009-03-26
WO2007006992A3 (fr) 2007-03-15

Similar Documents

Publication Publication Date Title
US8191119B2 (en) Method for protecting against denial of service attacks
KR100932834B1 (ko) Ｓｉｐ 메시지 프로세싱 방법
CN105491001B (zh) 一种安全通讯方法和装置
EP1902564A2 (fr) Mecanisme de protection des reseaux h.323 pour les fonctions d'etablissement d'appel
EP2692089B1 (fr) Mécanisme de redirection entrante sur un proxy inverse
EP1683388A2 (fr) Methode de gestion de la s curit d' applications avec un module de securite
WO2011073560A1 (fr) Acces a un reseau de distribution de contenu numerique
EP2484084A2 (fr) Procede et dispositifs de communications securisees contre les attaques par innondation et denis de service (dos) dans un reseau de telecommunications
WO2011151573A1 (fr) Procede et dispositifs de communications securisees dans un reseau de telecommunications
WO1998013990A2 (fr) Procede et systeme pour securiser les prestations de service des operateurs de telecommunication
EP3732849B1 (fr) Procédé et système d'identification de terminal d'utilisateur pour la réception de contenus multimédia protégés et fournis en continu
WO2015097363A1 (fr) Procédé de ralentissement d'une communication dans un réseau
EP3815335A1 (fr) Procédés de vérification de la validité d'une ressource ip, serveur de contrôle d'accès, serveur de validation, noeud client, noeud relais et programme d'ordinateur correspondants
EP2785029B1 (fr) Procédé et dispositif de transmission d'un appel masqué, procédé et dispositif de réception d'un appel masqué, signal de transmission d'un appel masqué, et programme d'ordinateur correspondant
EP2365686B9 (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
WO2006082296A2 (fr) Procede et dispositif de detection d'usurpations d'adresse dans un reseau informatique
EP2466849B1 (fr) Distribution selective d'un flux multicast
WO2006134072A1 (fr) Procede de protection contre le piratage d'un terminal client utilisant une connexion securisee avec un serveur sur un reseau public
Lema et al. Security Enhancement of SIP Protocol in VoIP Communication
FR2943482A1 (fr) Procede et systeme de securisation de demandes applicatives
FR3076638A1 (fr) Procede de gestion d'un acces a une page web d'authentification
FR2950767A1 (fr) Procede de communications securisees dans un reseau de telecommunications

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20071220

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR

DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20100805

DAX Request for extension of the european patent (deleted)
RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: ORANGE

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20160202