EP1851933A1 - Procede de securisation d'un reseau de communication audiovisuelle - Google Patents

Procede de securisation d'un reseau de communication audiovisuelle

Info

Publication number
EP1851933A1
EP1851933A1 EP06726190A EP06726190A EP1851933A1 EP 1851933 A1 EP1851933 A1 EP 1851933A1 EP 06726190 A EP06726190 A EP 06726190A EP 06726190 A EP06726190 A EP 06726190A EP 1851933 A1 EP1851933 A1 EP 1851933A1
Authority
EP
European Patent Office
Prior art keywords
message
parameter
endpoint
type
control element
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
EP06726190A
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 EP1851933A1 publication Critical patent/EP1851933A1/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/102—Entity profiles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/102—Gateways
    • H04L65/1023—Media gateways
    • H04L65/103—Media gateways in the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/102—Gateways
    • H04L65/1033—Signalling gateways
    • H04L65/104—Signalling gateways in the network
    • 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
    • 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 of audiovisual communication networks and particularly communication networks in which the transport uses packet routing.
  • This freedom of open networks has a counterpart which is that of greater vulnerability to malicious elements, a vulnerability that is more rarely encountered in proprietary networks.
  • Recommendation H.323 specifies endpoints such as terminals (terminals), gateways (gateways), multipoint control units (MCUs), or more generally any entity capable of generating or receiving calls by processing associated information flow.
  • Recommendation H.323 still specifies gatekeeper elements with which endpoints are logged in order to communicate.
  • Recommendation H.225 defines the signaling protocols on which H.323 networks and equipment are based. The messages and protocols defined in H.225 enable the endpoint registration and de-registration functions for gatekeeper elements, admission and call setup functions. call clearing, terminal location and information requests on the network elements.
  • Recommendation H.225 focuses on the exchange of signaling between two entities in the H.323 network, but not on the security related to these messages.
  • Recommendation H.235 which focuses on the security of H.323 systems, defines authentication, data integrity, confidentiality, and non-repudiation mechanisms, but does not address content. semantics of H.225 messages.
  • the subject of the invention is a method of securing an audiovisual communication network in which a first endpoint exchanges messages with a control element.
  • the messages transmit parameters recorded or to be recorded in the control element to allow the first endpoint to communicate with at least a second endpoint recorded in the control element.
  • the method is remarkable in that it comprises an observation step of detecting whether a set of parameters among the parameters transmitted in a message is not consistent with a current state of the recipient of said message.
  • the set of parameters is consistent if each parameter in the set does not match any parameter of the same endpoint type and value stored in the control element. or if there is a set with the same number of parameters of types and values respectively identical for a single endpoint already registered in the control element.
  • the parameter set is not consistent if a source parameter does not have the same value as the source parameter of the control element with which the point endpoint is registered or if a parameter designating the endpoint does not have the same value as the parameter of the same known endpoint type.
  • the security method comprises an authorization step of detecting for a parameter that can be associated with a control:
  • the transmitted parameter is of endpoint identifier type, if the value of the transmitted parameter that is associable does not belong to a range of identifier values provisioned for the endpoint.
  • the set of parameters to be coherent is defined according to the nature of the message transmitted such as recording, deregistration, location, information, admission or establishment.
  • the method advantageously comprises an evaluation step of detecting when the message contains a recording validity duration type parameter, if said parameter has a value less than a predefined threshold.
  • the security method comprises a monitoring step consisting in detecting whether a confirmation message received by the recipient is not preceded by a corresponding message of the request type sent by said recipient.
  • the security method comprises an inspection step of detecting whether a source address of the message is of different value from a parameter value contained in the message to indicate a transport address to which to send a response to said message. . - AT -
  • FIG. 1 shows an exemplary network architecture to which the invention applies;
  • Figure 2 illustrates control element behaviors for registration messages;
  • FIGS. 3 to 8 illustrate possible attacks with respect to the behaviors illustrated in FIG. 2;
  • FIG. 9 illustrates control element behaviors for record deletion messages
  • FIGS. 10 and 11 illustrate possible attacks with respect to the behaviors illustrated in FIG. 9;
  • FIG. 12 illustrates control element behaviors for location or information messages
  • FIGS. 13 and 14 illustrate possible attacks with respect to the behaviors illustrated in FIG. 12;
  • Figure 15 illustrates control element and endpoint behaviors for admission and establishment messages
  • FIGS. 16 to 18 illustrate possible attacks with respect to the behaviors illustrated in FIG. 15;
  • FIG. 19 shows security method steps relating to the recording
  • FIG. 20 shows an observation step for detecting incoherent parameters
  • - Figure 21 shows an authorization step to detect parameters that are not allowed
  • FIG. 22 shows security method steps relating to record deletion
  • FIG. 23 shows securing process steps relating to location and information
  • Figure 24 shows security process steps related to admission and establishment.
  • Figure 1 shows an example of an H.323 network architecture to describe associated vulnerabilities and attacks that have been demonstrated in a lab environment.
  • a packet transport network 6 is arranged to connect several H.323 type end points such as terminals 1, 2 and a gateway 3 so as to constitute an audiovisual communication network such as a voice over IP network. usually called VoIP network.
  • the gateway 3 makes it possible to connect to the audiovisual communication network, terminals arranged to connect to other networks.
  • a control element 4 (gatekeeper in the H.323 terminology) is arranged to record the endpoints authorized to participate in audiovisual communications.
  • Each endpoint 1, 2, 3 is specified respectively by a transport address RA1, RA2, RA3 for its channel named RAS which carries three functions: registration, admission and status, a transport address CSA1, CSA2, CSA3 for its call signaling CS channel and one or more ALI AS 1, ALIAS2, ALIAS3 identifiers.
  • RAS transport address
  • CSA1 transport address
  • CSA2 transport address
  • CSA3 call signaling CS channel
  • An endpoint such as for example here represented the terminal 1 and the gateway 3, can also be respectively equipped with a TOKEN1, TOKEN3 indicator according to the recommendation H.235, to reinforce the identification.
  • the network 6 may contain one or more unrepresented filter elements which are provided for monitoring the signaling messages exchanged between the endpoints 1, 2, 3 and the control element 4, in accordance with the H.323 recommendations. , H.225 and H.235.
  • the method explained later makes it possible to secure the network against an attacker 5 who simulates an H.323 terminal. It is assumed that the attacker 5 is able to generate signaling messages outside any temporal constraint, conforming to Recommendations H.323, H.225 and H.235, both from the point of view of the format and the fields. information used.
  • the attacker 5 can set the information fields of the signaling messages to the values necessary to conduct his attack, can send the signaling messages that he generates to the control element 4 by bypassing, if necessary, the filtering entities. deployed in the transport network.
  • the means used by the attacker 5 to bypass the filtering entities of the network are outside the scope of the invention.
  • the attacker knows at least one range of identifiers (ALIAS) and a range of transport addresses in which the endpoints are recorded. In the most common case, it will be for the identifiers of a range of telephone numbers and or a range of IP addresses in which the endpoints are recorded. The method by which the attacker comes to know this information is beyond the scope of the invention.
  • Figure 2 presents an example of possible transitions and steps of an H323 control element (GateKeeper) for the sole purpose of illustrating behaviors in accordance with Recommendations H323, H225 and H235 for Registration Request (RRQ) , Registration ConFirm (RCF) registration confirmation messages and RRJ (Registration ReJect) registration refusal messages.
  • GateKeeper Registration ConFirm
  • Registration is the process by which an endpoint informs the control element of its transport addresses and associated identifier (s) (ALIAS) at those addresses.
  • a behavior C1 of the control element is illustrated by a transition 12 validated by a reception of RRQ message supposed to come from the endpoint.
  • the control element analyzes particularly received values CSAr, RA r , ALIASr, TTLr and KAL r in the following fields of the RRQ message.
  • RRQ message In the RRQ message:
  • a CSA (CaII Signal Address) field is intended to contain a transport address used for the end-point signaling channel CS (CaII signaling);
  • a RA (Ras Address) field is intended to contain a transport address used for the RAS channel serving the registration, admission and status functions (Registration Admission Status);
  • an ALIAS field is intended to contain one or more endpoint identifiers such as a telephone number, an identifier e164, an identifier
  • a TTL Time To Live field is intended to contain a period of validity of the recording.
  • the control element considers that the recording has expired as illustrated by a transition 14 and a step 15;
  • a KAL field (Keep ALive) is intended to be set to false, for example 0, when the endpoint considers itself not yet registered with the control element and indeed, for example 1, for a maintenance of the record.
  • the record maintenance results from a re-transmission of RRQ messages by the endpoint to the control element, before expiration of the recording validity period.
  • the recording method may be periodically repeated by the endpoint.
  • a C2 behavior of the control element is illustrated by a step 11 in which the control element is constantly listening for RRQ message receptions.
  • a behavior C3 of the control element on this subject is illustrated by a step 19 in which the control element sends an RCF message to the address RA r analyzed in FIG. step 13 after setting the recorded values RA e and TTL e to the received values RA r and TTL r as long as there is a TTL value r accepted by the control element.
  • the behavior C3 of the control element on this subject is also illustrated by a step 27 in which the control element sends a message RRJ to the address RA r analyzed in step 13.
  • C4 behavior of the control element consists in replying with an RCF message when the received RRQ message designates the same transport address for the CS channel and the same identifier (ALIAS) as an endpoint already registered with it .
  • C4 behavior is illustrated by a trigger step 19 the sequence of transitions 16, 18 or the sequence of transitions 20, 22.
  • the transition 16 is validated when the control member finds a record containing a value ALIAS e equal to the received value ALIASr.
  • the transition 18 is validated when the control element finds that the received value CSA r is equal to a value recorded CSA e in the same record as that containing the value ALIAS e .
  • the transition 20 is validated when the control element discovers a record containing a value CSA e equal to the received value CSA r .
  • the transition 22 is validated when the control element finds that the received value ALIAS r is equal to a registered value ALIAS e in the same record as that containing the value CSA e . According to a C5 behavior, if the control element receives a message
  • the control element may confirm the request or return a RRJ message indicating that it is a duplicate alias.
  • the behavior C5 is illustrated by a triggering following transitions 16, 24, of the step 27 on validation of a transition 26 or of the step 19 following a validation of a transition 28.
  • the transition 16 is validated when the control element discovers a record containing an ALIAS value e equal to the value received ALIAS n .
  • the transition 24 is validated when the control element finds that the value received CSA r is different from the value recorded CSA e in the same record that contains the value ALIAS e .
  • Transition 26 is valid provided that the control element declines any value received CSA r for a record containing a different CSA e value.
  • the transition 28 is validated in the absence of such a condition, for example to allow a migration by replacing in a step 29, the value recorded CSA e by the received value CSA r before activation of step 19. According to a behavior C6, if the control element receives a message
  • the behavior C6 is illustrated by a triggering following transitions 20, 30, of a step 33 on validation of a transition 32 or of a step 35 on validation of a transition 34.
  • the transition 30 is validated when the control element discovers a record containing an ALIAS value e different from the value received ALIAS r .
  • the transition 32 is validated when the RRQ message is of the additive type.
  • the transition 34 is validated when the RRQ message is not of the additive type.
  • the value received ALIAS n is added to the list of registered values ALIAS e .
  • the received value ALIASr replaces the registered value ALIAS e .
  • An endpoint can send an RRQ message by specifying a TTL (Time To Live) validity value.
  • TTL Time To Live
  • a C7 behavior of the control element is to consider that the endpoint record has expired and delete its registration.
  • the behavior C7 is illustrated by the step 15 triggered following the transition 14 validated by each timeout TTL allocated to a record identified by an EPID key (EndPoint Identifier).
  • step 15 the entire identified record is deleted, which generally causes an URQ message to be sent to the endpoint which is then forced to acknowledge the de-registration request. It is indicated that the TTL validity period may also be set at the initiative of the control element and that the control element may deny a TTL value requested by the endpoint.
  • a behavior C8 a first endpoint record is made by setting the KAL field (keepAlive) to false and the record keeping requests are made by setting the KAL field to true.
  • the behavior C8 is illustrated by a transition 38 validated when the value KAL r received in the RRQ message is set to false.
  • the transition 38 activates a step 39 in which the control element generates an EPID value e to identify a new record intended to store the received values CSA r and ALIASr, normally detected absent from any previous record by validation of a transition 36.
  • the transition 36 is typically validated when there is no recorded value ALIAS e and no recorded value CSA e respectively equal to the received value ALIAS n and the received value CSA r .
  • the EPID identity key is then used at the endpoint to identify a previous record with the control element, particularly when the KAL field is set to true.
  • the recording is confirmed at the endpoint by sending a RCF message in step 19 in which the recorded value RA e and possibly the recorded value TTL e , are respectively set to values equal to the received values RA r and TTL r in the RRQ message.
  • a transition 40 is validated when an attacker decides to conduct an attack A1 aimed at knowing the point aliases. endpoints recorded on the control element.
  • the attacker sends to the control element GK (Gatekeeper), an RRQ message whose RA field contains a value Ra t equal to the address RA (attacker) of the channel Attacker RAS, the CSA field contains a CSA t value equal to the attacker CS address of the attacker CS channel, and the ALIAS field contains an ALIAS t value that belongs to the alias range managed by the GK control element.
  • the attacker receives back a message RRJ or RCF.
  • Receiving an RRJ message with the cause "duplicateAlias" meaning that the alias is already registered on the control element validates a transition 42 that activates a step 43 in which the attacker finds that the ALIAS value t is equal at an endpoint alias value checked in.
  • Receiving an RCF message validating a transition 44a or an RRJ message with a different cause of "duplicateAlias" validating a transition 44 activates a step 45 in which the attacker finds that the transmitted alias was not recorded on the control element.
  • the attacker knows the aliases of the endpoints recorded on the control element. It is indicated that the transition 42 can also be validated by a lack of reception of a message from the control element, for example after a certain delay. Indeed, if the control element sends an RCF message to the regular endpoint, this can be interpreted in step 43 as a registered value existence of identifier ALIAS e equal to the transmitted value ALIAS t .
  • the attacker can adapt his RRQ message emissions to a frequency low enough to drown in the regular stream of messages received by the control element. To increase the stealth of the attack, the scan can be done randomly in the target alias range.
  • a transition 46 is validated when an attacker decides to carry out an attack A2 aimed at knowing the address of an endpoint whose attacker knows the alias.
  • the attacker has previously obtained knowledge of the alias of at least one registered endpoint, for example by means of the attack A1.
  • a step 47 activated as a result of the transition 46 the attacker sends to the control element GK (gatekeeper) a message RRQ whose RA field contains a value Ra t equal to the address RA (attacker) of the channel RAS of the attacker, the CSA field contains a CSA 4 value which belongs to the address range for the signaling channel managed by the control element GK, the ALIAS field contains a value ALIAS t equal to the value ALIAS e known from a registered endpoint.
  • the attacker receives in return an RRJ message validating a transition 48 or an RCF message validating a transition 50b.
  • the transition 48 activates a step 49 in which the attacker finds that the address put in the CSA field is not that of the registered endpoint and the search process is reiterated with a new address of the address range. signaling channel managed by the control element.
  • the transition 50b activates a step 51 in which the attacker finds that the address put in the CSA field is that of the registered endpoint and marks the end of the search process. If the behavior of the control element does not conform to C3, the RCF may be sent to the registered endpoint and the attacking terminal may receive no feedback from the RCF. This lack of response validating a transition 50 is similar to receiving RCF message which has the effect of activating step 51.
  • the attacker knows the transport address for the CS channel corresponding to the alias of the registered endpoint.
  • the attacker also acquires knowledge of the EPID identity key e of the registered endpoint.
  • the attacker can adapt his RRQ messages to a frequency low enough to drown in the regular stream of messages received by the control element and the scan can be done randomly in the range targeted addresses.
  • a transition 52 is validated when an attacker decides to conduct an attack A3 aimed at unregistering a regular endpoint of the control element in a first manner.
  • the attacker has previously obtained knowledge of the alias and the transport address for the signaling channel CS of at least one registered endpoint, for example by means of the attacks A1 and A2.
  • the attacker sends to the control element GK (gatekeeper) a non-additive RRQ message whose RA field contains a value Ra t equal to the address RA (attacker) of the attacker's RAS channel, the CSA field contains a CSA t value equal to the CSA e value that the attacker knows about a registered endpoint, the ALIAS field contains an ALIAS value t equal to a value unregistered alias on the control element or no identifier value when the control element accepts RRQ messages with an empty ALIAS field.
  • GK gatekeeper
  • the attacker Based on the behaviors C3 and C6, the attacker receives a registration confirmation RCF message meaning that the new alias given by the attacker in the RRQ has replaced the alias of the regular endpoint.
  • the RCF message which also contains the new EPID key value for this record, validates a transition 56 which activates a step 57 which allows the attacker to become aware of interfering with the recording as he pleases.
  • a transition 58 is validated when an attacker decides to conduct an A4 attack to unregister a regular endpoint of the control element in a second manner.
  • the attacker has previously obtained knowledge of the alias and the transport address for the signaling channel of at least one registered endpoint, for example by means of the A1 and A2 attacks. .
  • a step 59 activated following the transition 58 the attacker sends to the control element GK (gatekeeper) a message RRQ whose RA field contains a value Ra t equal to the address RA (attacker) of the channel RAS of the attacker, the CSA field contains a CSA t value equal to the CSA e value and the ALIAS field contains an ALIAS value t equal to the alias value ALIAS e that the attacker knows about a point d end recorded on the control element.
  • the TTL field in the RRQ message is set to a low ⁇ delay value, typically less than the normal recording time of the system, and the KAL field is set to true to indicate that it is a record keeping.
  • the control element accepts this request to keep the record and at the end of the delay ⁇ considers that the endpoint is deregistered. Regardless of whether or not an RCF message is received depending on whether or not the control element conforms to the behavior C3, the attacker knows that at the end of the delay ⁇ validating a transition 60, the regular endpoint is deregistered automatically by the control element. In parallel with the activation of a step 61 following the transition 60, the control element generally sends a de-registration message (URQ) to the regular endpoint. At the end of the attack the regular endpoint must proceed to a new recording.
  • URQ de-registration message
  • a transition 62 is validated when an attacker decides to carry out an A5 attack aimed at usurping the identity of an endpoint regular.
  • a first preliminary step consists of determining the ALIAS and CSA parameters of a regular endpoint by applying the methods described in connection with the A1 and A2 attacks, or any other method leading to an identical result.
  • a second phase preliminary to the attack A5 consists of provoking a temporary deregistration of the regular end point by applying the methods described in connection with attacks A3 or A4, or any other method leading to an identical result.
  • temporary is meant that the deregistration only lasts until the regular endpoint re-registers.
  • a step 63 activated as a result of the transition 62, the attacker sends to the control element GK an RRQ message whose RA field contains a value Ra t equal to the address RA (attacker) of the RAS channel.
  • the attacker the CSA field contains a value CSA t equal to the value of the attacker's address of the attacker CSA (Attaq) and the field ALIAS contains a value ALIASt equal to the value of identifier ALIAS of the point d ' end of which the attacker seeks to impersonate.
  • a transition 64 validated by an RCF message reception activates a step 65 that informs the attacker that it is now registered with the control element under the alias of the regular endpoint. The regular endpoint can then no longer register because its identification alias is now assigned to the attacking terminal. The attacking terminal can then make or receive calls instead of the regular endpoint.
  • a transition 66 is validated when an attacker decides to carry out an attack A6 aimed at creating a desynchronization between the states of a control element and an endpoint.
  • This attack is particularly applicable to H.323 networks in which the endpoints maintain a record by periodic sending of RRQ messages.
  • a first preliminary step consists in determining the ALIAS and CSA parameters of a regular endpoint, by applying the methods described with regard to the A1 and A2 attacks, or any other method leading to an identical result.
  • a second preliminary phase to the attack consists in causing a temporary deregistration of the regular end point, by applying the method described in connection with the attack A4, or any other method leading to an identical result.
  • a step 67 activated following the transition 66 the attacker sends a new RRQ message whose fields ALIAS and CSA contain the ALIAS e and CSA e values of the regular endpoint, and the KAL field is set to false to signify that it is a new record.
  • the control element accepts this new record and returns an RCF message to the regular endpoint or to the attacker, depending on the positioning of the RA field in the RRQ message and the compliance of the element from control to C3 behavior.
  • the regular endpoint tries to re-register, its action fails because it has already been re-registered by the attacker.
  • the attacker therefore performs a deregistration and re-registration of the regular endpoint, before the regular endpoint has done it himself.
  • the control element is in a state where it expects from the regular endpoint RRQ messages with a KAL value of true, since it has already received the RRQ message sent by the attacker with a KAL value. to false.
  • the regular endpoint tries to re-register by sending RRQ messages with a false KAL value, and therefore fails to do so.
  • Figure 9 shows an example of transitions and possible steps of an H323 control element (GateKeeper) for the sole purpose of illustrating behaviors according to the recommendations H323, H225 and H235 for URQ (ReQuest Registration) de-registration requests, UCF Unregistration Confirmation Messages (ConFirm Unregistration) and URJ Unregistration Rejection Messages (Unregistration ReJect).
  • GateKeeper GateKeeper
  • An endpoint can at any time send an URQ message to the control element to remove its registration from this control element.
  • a behavior C9 of the control element is illustrated by a transition 68 validated by a reception of URQ message supposed to come from the endpoint.
  • the control element analyzes particularly received values CSA r , ⁇ ALIAS, ⁇ , and EPIDr in the corresponding fields of the message URQ.
  • the control element can at any time delete the registration of an endpoint, for example at the expiration of the TTL value of the record identified by the key EPID as illustrated by a transition 70 which activates a step 71 in which an URQ message is sent to destination of the RA transport address contained in the EPID referenced record.
  • the endpoint is forced to accept the record deletion issued by the control element and must respond to it with a UCF message such as that which validates a transition 72 to activate a step 73 in which the record identified EPID. is deleted.
  • an endpoint sends an URQ request to a control element that contains a list of ⁇ ALIAS, ⁇ fields and the control element accepts the request, it must remove from the record only the identifiers specified in the message URQ.
  • This behavior C11 is illustrated by a transition 74 which activates a step 75 in which the identifiers of the list ⁇ ALIASr ⁇ are removed from the list ⁇ ALIAS e ⁇ of the identifiers registered for this endpoint and a UCF message is sent to the point end.
  • the equality of the two lists validates a transition 78 which activates a step 77 in which a UCF message is sent to the transport address RA contained in the record referenced by the EPID key.
  • a C13 behavior involves the deregistration of all aliases identifying that endpoint, and thus the endpoint himself.
  • a behavior C14 When a control element sends an URQ message to an endpoint, a behavior C14 exempts the control element from completing the EPID (endpoint identifier) field of the URQ.
  • C9 to C14 behaviors are vulnerable to attacks such as those illustrated in Figures 10 and 11.
  • a transition 80 is validated when an attacker decides to conduct an A7 attack to unregister an endpoint from the control element in a first manner.
  • the attacker is aware of the values of the CSA transport address for the CS channel and the EPID parameter of the endpoint that he wishes to de-register. This knowledge can be acquired by first conducting one of the attacks A1 to A6, or by any other method leading to an identical result.
  • the transition 80 activates a step 81 in which the attacker sends to the control element (GK) an URQ message whose parameter values CSA t and EPID t are equal to the previously determined CSA e and EPID (PE) values, and not containing an ALIAS field.
  • the control element Based on the behaviors C9 and C12, the control element accepts the de-registration request and sends a UCF message to the endpoint designated by the CSA and EPID parameters. Note that the attacker does not need to complete the ALIAS field of the URQ because of the behavior C12. The result is that the endpoint is temporarily unregistered from the control element. This result is similar to A3 and A4 attacks and may be followed by an identity theft attack before the regular terminal has time to re-register.
  • a transition 82 is validated when an attacker decides to conduct an A8 attack to unregister an endpoint in a second way.
  • the attacker is aware of the values of the CSA transport address for the CS channel and the RA transport address for the end-point RAS channel that he wants. deregister. This knowledge can be acquired by first conducting one of the attacks A1 to A6, or by any other method leading to an identical result.
  • the transition 82 activates a step 83 in which the attacker sends to the endpoint (PE) an URQ message whose CSA parameter has the value CSA t , the value CSA e previously determined, and containing no field ALIAS, neither EPID field.
  • the endpoint Based on behaviors C10, C13 and C14, the endpoint accepts the de-registration request and returns a UCF message to the control element with which it was registered. Indeed, the C13 and C14 behaviors dispense the attacker from completing the ALIAS and EPID fields of the URQ message. The result is that the endpoint is unregistered, and must initiate a new registration request with the control element. If this attack is iterated in a very short time to a large number of endpoints, it causes an influx of messages to the control element (GK) that can cause it to be disabled. In addition, depending on the operation of the control element, the attack A8 can create a state of desynchronization between the endpoint and the control element since the latter receives a new registration request from a point endpoint that he considers already registered.
  • GK control element
  • FIG. 12 presents an example of transitions and possible steps of an H323 control element (GateKeeper) and an endpoint H323 (Endpoint) for the sole purpose of illustrating behaviors according to the recommendations H323, H225 and H235 for LRQ (Location ReQuest) locator request messages, LCF (Location ConFirm) location confirmation messages, and Location ReJect (LRJ) location refusal messages as well as IRQ (Information ReQuest) information request messages, and IRR (Information ReQuest Response) response messages.
  • LRQ Location ReQuest locator request messages
  • LCF Location ConFirm
  • LRJ Location ReJect
  • An endpoint or control element may at any time send an LRQ message to a control element to obtain the location information of a third endpoint of which it knows at least one alias.
  • the location information returned by the control element includes, in particular, parameter values CSA, RA and D1.
  • the field D1 is intended to contain one or more destination endpoint identifiers of an audiovisual communication such as, for example, a telephone number, an identifier e164, an H.323 identifier, an e-mail address or the like.
  • a control element behavior C15 is illustrated by a transition 84 validated by receipt of an LRQ message that is expected to originate from an endpoint or other regular control element.
  • a step 85 activated by a validation of the transition 84 the control element analyzes values received ALIAS r , and particularly RPA r in an RPA field (RePIy Address) of the LRQ message which is intended to contain an entity network address to which must be returned a response to the message LRQ or an IRQ message.
  • a step 89 activated by a transition validation 88 following the step 85 the control element sends to the address RPA r , a LCF message containing values CSA e , RA e and Dl e recorded for the endpoint recognized by its identifier ALIAS e equal to the received value ALIAS r during a transition validation 88.
  • the value Dl e is transmitted in the parameter field Dl (Destination Info) in the case of a message LRQ or ARQ seen later or (Destination Address) in the case of a type of call setup message usually called Setup and seen later.
  • a control element receiving an LRQ message designating an endpoint that is not registered with it shall respond by returning a LRJ message when the LRQ message was received on the RAS channel of the control element.
  • This behavior C16 is illustrated by the transition 86 which activates a step 87 for sending the location denial message LRJ.
  • the transition 86 is validated when no registered identifier value ALIAS e corresponds to the received value ALIAS r .
  • a control element behavior C17 receiving an LRQ request responds to the network address designated by the RPA parameter of the LRQ message, whether it is an LCF or LRJ response.
  • a control element may at any time request usage information from an endpoint by sending it an IRQ message which specifies in CRV and CID fields values corresponding to a desired call.
  • the CRV field (CaII Reference Value) is intended to contain a call reference and the CID (CaII Identifier) field is intended to contain a call identifier.
  • CaII Reference Value is intended to contain a call reference
  • CID CaII Identifier
  • Receipt of an endpoint IRQ message y validates a transition 90 which activates a step 91 in which the endpoint becomes aware of CRV values r , CID r and RPA r received in the IRQ message.
  • CRV r validates a transition 92 in the endpoint.
  • an endpoint When an endpoint receives an IRQ request with the CRV field set to 0 while an absence of an ongoing call validates a transition 94, the endpoint shall assume a C20 behavior of responding to the IRQ message providing in a step 95, all other information available to it outside the call information.
  • the endpoint When an endpoint receives an IRQ request with the CRV field set to a non-zero value that validates a transition 98, the endpoint responds to the IRQ message by providing in a step 99 the information it has relative to the call identified by the received CID value r .
  • Steps 95 and 97 also highlight a behavior C21 according to which an endpoint receiving an IRQ request must respond to the network address designated by the RPA parameter of the IRQ message, and not to the source address (AS) of the IRQ. IRQ packet.
  • a transition 100 is validated when an attacker decides to conduct an attack A9 aimed at retrieving the information on the endpoints registered with the control element.
  • the transition 100 activates a step 101 in which the attacker sends a message LRQ to the control element with the field D1 positioned at an alias value ALIAS t contained in the range of aliases ⁇ ALIAS ⁇ managed by the element control (GK), and where the RPA field designates the address RA t of the attacker.
  • the attacker receives back a message LRJ which validates a transition 102 or an LCF message which validates a transition 104.
  • the reception of a message LRJ means in a step 103 that this alias is not registered with the control element.
  • Receiving an LCF message indicates in a step 105 that this alias is registered with the control element and further provides endpoint sensitive information, such as the parameter values CSA e , RA e .
  • endpoint sensitive information such as the parameter values CSA e , RA e .
  • the source address (AS) for the transmission of the LRQ packet may be that of the attacker himself or that of an H.323 entity from which the control element would accept to receive a request.
  • RSQ the source address
  • a transition 106 is validated when an attacker decides to carry out an attack A10 aimed at recovering the usage information of an endpoint.
  • the transition 106 activates a step 107 in which the attacker sends an IRQ message to the endpoint PE targeted by his address in the RA field, with the CRV and CID fields set to 0 and whose RPA field designates the address of the attacker.
  • the endpoint Based on the behaviors C18 and C19, the endpoint must accept the IRQ message.
  • the endpoint In the case where there is a call in progress, or even if there is no call in progress after C20, the endpoint must respond to this IRQ request by returning an IRR message to the user. address specified in the RPA field after C21, ie to the attacker.
  • the attacker Upon receipt of the IRR message validating a transition 108, the attacker knows endpoint sensitive information, such as CSA (PE), RA (PE), ALIAS (PE), and EPID (PE).
  • endpoint sensitive information such as CSA (PE), RA (PE), ALIAS (PE), and EPID (PE).
  • the result of the attack A10 is very similar to that of the attacks A1 and A2, and furthermore the attack A10 can be reiterated towards the set of endpoints recorded with the control element.
  • the source address (AS) for sending the IRQ packet may be that of the attacker himself or that of an H.323 entity from which the endpoint would accept to receive a request.
  • IRQ typically the control element in which the endpoint is registered.
  • the second case assumes that the attacker knows how to bypass the entities of network filtering and thus manages to impersonate the control element when sending the IRQ message.
  • FIG. 15 shows an example of possible transitions and steps of an H323 control element (GateKeeper) and an endpoint H323 (Endpoint) for the sole purpose of illustrating behaviors according to the recommendations H323, H225 and H235 for Admission Requq (ARQ) application messages, Admission Confirm (ACF) admission confirmation messages and Admission Reject (ARJ) admission rejection messages and Setup call setup messages .
  • ACF Admission Confirm
  • ARJ Admission Reject
  • one or more EPID r parameter values Dl r, r Sl or SCSA r with the received ARQ allow the control element to identify in step 111 the endpoint.
  • the SI (Src Info) field used for ARQ or Source Address messages used for Setup messages is intended to contain one or more aliases identifying a calling endpoint while the Destination Info (Dl) field is intended for to contain one or more aliases identifying a called endpoint.
  • step 113 When the control element sends in step 113 an admission acceptance confirmation ACF message, receipt of the ACF message by the calling endpoint validates a transition 112 which activates a step 115 in which the point of access end adopts a C23 behavior, respecting a parameter value cMod (callModel) specified in the ACF message.
  • the parameter "callModel" set to a "direct” value validates a transition 116 that activates a step 117 in which the endpoint sends the SetUp message directly to the called endpoint.
  • the "callModel” parameter set to a "GKR" (gatekeeperRouted) value validates a transition 118 that activates a step 119 in which the endpoint sends the SetUp message to the control element and this is the element of control that then relay to the called endpoint.
  • a behavior C24 makes the optional EPID parameter in the case where the SetUp message is sent directly to the endpoint called in step 117 and imposes the EPID parameter in the case where the SetUp message is sent to the control element in step 119
  • the SI and SCSA parameters of the Setup message are optional individually in the H.225 syntax.
  • the SCSA (srcCallSignalAddress) parameter used for ARQ or (sourceCallSignalAddress) messages used for Setup messages indicates a transport address for the CS signaling channel assigned to the calling endpoint.
  • a behavior C25 requires to include at least one of these parameters in the Setup message sent in step 117 or 119.
  • the Dl and DCSA parameters of the Setup message are optional individually in the H.225 syntax.
  • the DCSA (dstCallSignalAddress) parameter specifies a transport address for the CS signaling channel assigned to the called endpoint.
  • a behavior C26 imposes to include at least one of these parameters in the Setup message sent in step 117 or 119.
  • the parameter D1 must be preferred over DCSA parameter for message processing. If the SetUp message received by a called endpoint contains the SCSA parameter, a C27 behavior causes the value of this parameter to be transmitted by the called endpoint in the ARQ message that it sends to the element. control.
  • the routing mode of the Setup message belongs to a C28 behavior in which the control element can modify the DCSA destination information that it receives before issuing the corresponding SetUp message to the called entity in a step 93 activated by a transition 114 validated by receiving the Setup message from the calling endpoint.
  • a transition 120 is validated when an attacker decides to conduct an A11 attack to issue a call by spoofing the H.323 identity of a third party entity in a first manner.
  • a preliminary phase Attack A11 acquires the values of the EPID and ALIAS identification parameters of an endpoint registered with the control element. This acquisition of information can be carried out by one of the attacks A1 to A6, or by any other method leading to the same result.
  • the attacker sends to the control element an ARQ message whose fields EPID and SI are positioned at the values EPID e and ALIAS e previously determined.
  • the control element Based on the C22 behavior, and based on the EPID parameter values t and SI t , the control element identifies the calling endpoint as valid and returns an ACF message. Depending on the behavior of the control element, the ACF message is returned to the attacker who validates a transition 122, or on the contrary to the regular endpoint. In order to promote a validation of the transition 122, the parameter value SCSA t of the ARQ message may be forced to the attacker's CSA transport address, or if it is not accepted by the control element, at the CSA transport address of the regular endpoint.
  • the attacker continues the call in a step 123 by sending a SetUp message to the called control element or endpoint, following the call pattern information (cMOD) returned in the ACF message that validates the call. transition 122.
  • the EPID and SI parameters of the SetUp message will retain the information of the spoofed entity.
  • a failure to receive an ACF message means that the ACF message has been sent to the regular endpoint, the attacker then sends the Setup message as indicated previously based on the known call pattern information of the attacker .
  • the result of the attack is the possibility for the attacker to make a call by pretending to be a third party. Referring to Fig.
  • a transition 124 is validated when an attacker decides to conduct an A12 attack to issue a call by spoofing the H.323 identity of a third entity in a second manner.
  • a preliminary phase to the attack A12 consists of acquiring the values of the identification parameters ALIAS and possibly EPID of an endpoint registered with the control element.
  • the attacker sends a Setup message directly to the endpoint he wishes to call by setting the IF field of the Setup message to the ALIAS value e of the entity he wants to usurp. identity.
  • the EPID field of the Setup message is optional.
  • the called endpoint will send or not an ARQ message to the control element before accepting the call.
  • the IF information contained in the Setup message is retrieved by the called endpoint and inserted into the ARQ message that it sends to the control element.
  • the ARQ message sent by the called endpoint is logically accepted by the control element and after receiving the ACF message, the call establishment proceeds normally.
  • the SCSA parameter of the SetUp message may be omitted or set at the attacker's CSA transport address, to force the endpoint to respond to it at this address.
  • the result of the A12 attack is the possibility for the attacker to establish a call by pretending to be a third party. This result is in all respects similar to that of the attack A11, only the operating mode is different.
  • a transition 126 is validated when an attacker decides to conduct an attack A13 to issue a call by spoofing the H.323 identity of a third entity in a third way.
  • a preliminary phase to the attack A13 consists of acquiring the values of the identification parameters ALIAS of an endpoint registered with the control element.
  • the attacker sends to the control element an ARQ message containing its own parameters EPID and SI, followed in step 79 of a Setup message to the control element in which the parameter SI is changed to the ALIAS e value of the third party entity.
  • Step 79 is for example activated by a transition 128 validated by the reception of an ACF message from the control element.
  • the Setup message is sent directly to the called entity, which joins the attack A12.
  • the result of the attack A13 is in all respects similar to that of the attacks A11 and A12, only the operating mode is different.
  • the attacker needs to be registered with the control element to have EPID and SI record parameters.
  • the attacker may send in his Setup message his own EPID parameter value or be forced to send the EPID parameter value of the regular endpoint. It is reported that the experiments conducted on several systems have shown systems resistant to some of the attacks presented here but that these experiments have made it possible to detect at least one system vulnerable to each of these attacks while complying with the recommendations in the field.
  • Fig. 19 shows a series of steps 141 to 145 activated when a control element GK is addressed to a registration request type RRQ which validates a transition 140 and a step 146 when an endpoint is recipient of a record confirmation type RCF message that validates a transition 187.
  • an inspection step 141 tests whether the RA field of the RRQ message, intended to indicate a transport address to which a response to said message is transmitted, contains a value different from the source address of the message. .
  • a positive test response detects a filter condition F1.
  • An observation step 142 tests whether a set of values received
  • ALIASr, CSAr, RA r corresponds to a set of transmitted parameters P r i consistent with the current state of the control element.
  • the test uses a coherence function D1 executed from a step 147 with the received parameter values.
  • a negative test response detects a filter condition F2.
  • Step 148 tests whether for each parameter P r i there exists in the control element no already registered PE endpoint having a parameter P e i of the same type and value as P r i.
  • Step 149 tests whether for all the parameters P n - there exists in the control element a single registered PE endpoint having a set of as many parameters P e i of the same types and the same values that all the parameters Pn.
  • the function D1 returns a positive test response in the event of a positive response to one of the two tests of steps 148 and 149.
  • an observation step 143 tests if a set of received values ALIAS r , CSA r , RA r , EPIDr corresponds to a set of transmitted parameters P n consistent with the current state of the control element.
  • the test uses the coherence function D1 executed from step 147 with the received parameter values.
  • a negative test response detects a F3 filter condition.
  • An authorization step 144 tests whether an ALIAS / TOKEN association is authorized by calling on a coherence function D2 detailed with reference to FIG. 21.
  • a negative response feedback of the function D2 detects a filtering condition F4.
  • the function D2 receives in step 150 a parameter / witness association designation whose coherence is to be verified. For example, when the function D2 is called from step 144, the designation corresponds to a parameter value P n equal to the value ALIAS n and to a control value equal to the value TOKEN n if it is transmitted in the message H225 received. Two conditions are necessary for the verification of the authorization.
  • a transition 190 is validated when the value of the TOKEN witness is transmitted in the received message and a transition 191 is enabled when the value of the TOKEN cookie is not transmitted in the received message.
  • the witness within the meaning of recommendation H.235, is for example a secret key intended to accredit an associated parameter value.
  • Transition 190 activates a step 151 that tests whether the endpoint that the witness identifies has an attribute P e i of the same type and value as P r i. The first condition is checked in the event of a positive response to the test of step 151 or in the case of validation of the transition 191.
  • a transition 192 is validated when the associated parameter is not of the endpoint identifier type ALIAS and a transition 193 is validated when the associated parameter is of endpoint identifier type ALIAS.
  • the transition 193 activates a step 152 which tests whether the value of the parameter Pri is part of the range of ALIAS provisioned by the operator.
  • An ALIAS is provisioned when it is reserved by the operator at a given endpoint, regardless of whether that endpoint is already registered with the control element.
  • the second condition is checked in case of a positive response to the test of step 152 or in case of validation of transition 192.
  • the function D2 returns a negative test response in the event of a negative response to one of the two tests of the steps 151 and 152.
  • RRQ contains a value-validity parameter of receipt of TTL value r received less than a threshold predefined by the value operator ⁇ .
  • the value ⁇ will typically be less than the recording time applied by default in the network, and of the order of a few seconds. It is indicated that the threshold value may vary according to the architecture and equipment deployed by the network operator. Nevertheless, it is recommended not to exceed for ⁇ a value of 60 seconds.
  • a positive test response detects an F5 filter condition.
  • a monitoring step 146 tests whether the RCF message received by the regular endpoint from the control element (gatekeeper) with which it is registered does not follow no request message RRQ previously issued by this endpoint. A positive test response detects a filter condition F6.
  • an URQ received by a gatekeeper validates a transition 153 that activates steps 154-156.
  • Step 154 tests whether a set of received values AS r , CSA r , EPID r corresponds to a set of transmitted parameters P ri consistent with the current state of the control element by calling on the coherence function D1 executed from step 147 with the received parameter values.
  • a negative test response detects an F7 filter condition.
  • Step 155 tests whether the URQ message indeed contains an ALIAS parameter and whether a set of received values ALIAS r , CSA r , corresponds to a set of transmitted parameters P r i consistent with the current state of the control element. using the coherence function D1 executed from step 147 with the received parameter values.
  • a negative test response detects an F9 filter condition.
  • Step 156 tests whether a CSA / TOKEN association is authorized by calling on the detailed function D2 with reference to FIG. 21.
  • a negative response feedback from the function D2 detects a filtering condition F11.
  • An URQ received by an endpoint validates a transition 159 that activates a step 160 tests whether the source address AS is different from the transport address used for the RAS channel of the control element with which the point d endpoint is registered, or if the CSA parameter is not consistent because it is different from the transport address for the CS endpoint channel.
  • a positive test response detects an F8 filter condition.
  • a UCF message received by the control element or the endpoint respectively validates a transition 157 or 161 which respectively activates a monitoring step 158 or 162 which tests whether this message does not correspond to any URQ request message issued in advance. direction of the network element from which the UCF message originates.
  • a positive test response detects an F10 filter condition.
  • inspection steps 169, 173 test whether the RPA field of an LRQ or IRQ message, intended to indicate a transport address to which a reply to said message is sent, contains a value different from the the source address of the message.
  • a positive test response detects an F12 filter condition.
  • An LRQ message to the control element validates a transition 163.
  • An IRQ message to the endpoint validates a transition 170.
  • the step 169 is activated by validating the transition 163.
  • the step 173 is activated by validation of the transitions 170.
  • the transition 163 activates an observation step 164 which tests the consistency of the parameter D1 of the message LRQ as registered identifier with an ALIAS value e with the control element having received the message LRQ.
  • a negative test response detects an F13 filter condition.
  • the transition 163 activates an observation step 165 making use of the function D1 by subjecting it to the set of parameters ⁇ D1, EPID ⁇ .
  • a negative test response detects an F14 filter condition.
  • the transition 170 activates an observation step 171 in which a current state of the endpoint comprises the transport address RA (GK) of the control element with which the endpoint is registered.
  • the source address of the IRQ message is a consistent parameter if its value is equal to the RA (GK) address.
  • the function of step 171 is to detect an inconsistency which then constitutes a filtering condition F15.
  • the transition 170 activates an observation step 167 which, when the IRQ message transmits a non-zero CRV parameter, tests whether a set of received values CRV r , CID r corresponds to a set of transmitted parameters P r i consistent with the state current of the endpoint. The received values are consistent if they correspond to an ongoing call. A negative test response detects an F16 filter condition.
  • the transition 163 and the transition 170 respectively activate the authorization step 168 and the authorization step 174 which test whether the AS / TOKEN association is authorized using the D2 function.
  • the address source AS is equivalent to an address RA of the same value.
  • a negative response to a test detects an F17 filter condition.
  • an ARQ message and a Setup message to the control element respectively validate a transition 175 and a transition 181.
  • a message to an endpoint validates a transition 185.
  • the transition 175 activates an observation step 176 which tests whether a set of received values AS r , S r , EPID r corresponds to a set of transmitted parameters P r i consistent with the state current of the control element by using the coherence function D1 executed from step 147 with the received parameter values.
  • a negative test response detects an F18 filter condition.
  • the transition 181 activates an observation step 182 which tests whether a set of received values AS r , S r , EPIDr corresponds to a set of transmitted parameters P r i consistent with the current state of the control element by using the coherence function D1 executed from step 147 with the received parameter values.
  • a negative test response detects a filter condition F21.
  • the transition 175 activates an observation step 177 which tests whether a set of received values SCSA r , ASr, EPIDr corresponds to a set of transmitted parameters P r i consistent with the current state of the control element by using the coherence function D1 executed from step 147 with the received parameter values.
  • a negative test response detects a filter condition F19.
  • the transition 181 activates an observation step 183 which tests whether a set of received values SCSAr, AS r , EPIDr corresponds to a set of transmitted parameters P r i consistent with the current state of the control element by using the coherence function D1 executed from step 147 with the received parameter values.
  • a negative test response detects an F22 filter condition.
  • the transition 175 activates a step 178 which tests whether an EPID / TOKEN association is authorized by calling on the coherence function D2 detailed with reference to FIG. 21.
  • a negative response feedback of the function D2 detects a filtering condition F20 .
  • the transition 181 activates a step 184 which tests whether an association
  • EPID / TOKEN is authorized by calling on the coherence function D2 detailed with reference to FIG. 21.
  • a negative response feedback of the function D2 detects a filtering condition F23.
  • the transition 175 activates a step 179 which stores the values of fields Slr has SCSAr received with the ARQ message. Following step 179, a reception by the control element of a message on the signaling channel CS coming from the same endpoint as the message ARQ validates a transition
  • the transition 188 activates an observation step 180 in which a current state of the control element comprises the values stored in step 179.
  • Step 180 tests whether the values SU, SCSAr 8 received with the second message
  • Transition 185 activates an observation step 186 in which a current state of the endpoint includes the known endpoint DI (PE) and transport address (DCSA) values (PE).
  • Step 185 tests whether the values Dl r , DCSA r received with the message Setup are respectively equal to those known.
  • a negative test response detects an F25 filter condition.
  • step 41 is filterable by the step 142, even 143 because the CSA address of the attacker does not correspond to the CSA address of the attacked.
  • step 47 is filterable by step 142 because the address RA does not correspond to the address RA of the attacked.
  • step 53 is filterable by step 142 because the endpoint identifier is not not consistent with the transport address for call signaling channel.
  • the step 67 is filterable by the step 142 if the address RA is that of the attacker or if it is not the case, the end point can remedy the attack thanks to step 146.

Landscapes

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

Abstract

Dans un réseau de communication audiovisuelle, un premier point d'extrémité échange des messages avec un élément de contrôle, les messages (140, 187) transmettant des paramètres enregistrés ou à enregistrer dans l'élément de contrôle pour permettre au premier point d'extrémité de communiquer avec au moins un deuxième point d'extrémité enregistré dans l'élément de contrôle. Le réseau de communication est sécurisé par un procédé qui comprend une étape d'observation (142, 143) consistant à détecter si un ensemble de paramètres parmi les paramètres transmis dans un message, n'est pas cohérent avec un état courant du destinataire du dit message.

Description

Procédé de sécurisation d'un réseau de communication audiovisuelle.
Le domaine de l'invention est celui des réseaux de communication audiovisuelle et particulièrement des réseaux de communication dans lesquels le transport utilise le routage de paquets. On observe un succès croissant de tels réseaux face aux réseaux à commutation de circuit, succès attribuable entre autre à la souplesse d'utilisation de la bande passante et à la liberté de mise en œuvre offerte. Cette liberté de réseaux ouverts a une contrepartie qui est celle d'une plus grande vulnérabilité à des éléments mal intentionnés, vulnérabilité qu'on rencontre plus rarement dans des réseaux de type propriétaire. Par communication audiovisuelle on entend en fait toute communication multimédia pour laquelle on connaît des équipements et architectures de réseaux tels que ceux basés sur la Recommandation H.323 de I1UIT-T "Packet Based multimédia communication Systems", et les Recommandations dérivées dont en particulier les Recommandations H.225 "CaII Signalling protocols and média stream packetization for packet-based multimédia communication Systems" et H.235 "Security and encryption for H-series (H.323 and other H.245-based) multimédia terminais".
La recommandation H.323 spécifie des points d'extrémités (endpoint) tels que des terminaux (terminal), passerelles (gateway), unités de contrôle multipoint (MCU), ou plus généralement toute entité capable de générer ou recevoir des appels en traitant les flux d'informations associés. La recommandation H.323 spécifie encore des éléments de contrôle des communications (gatekeeper) auprès desquels sont enregistrés les points d'extrémités pour pouvoir communiquer. La Recommandation H.225 définit les protocoles de signalisation sur lesquels sont basés les réseaux et équipements H.323. Les messages et protocoles définis dans H.225 permettent de réaliser les fonctions d'enregistrement et de désenregistrement des points d'extrémités (endpoint) auprès des éléments de contrôle (gatekeeper), les fonctions d'admission et d'établissement d'appels, de libération d'appels, de localisation de terminaux et de demandes d'informations sur les éléments du réseau. A propos de la sécurité des systèmes H.323, on sait que la Recommandation H.225 se focalise sur l'échange de signalisation entre deux entités du réseau H.323, mais pas sur la sécurité liée à ces messages. A l'inverse, la Recommandation H.235 qui est axée sur la sécurité des systèmes H.323, définit des mécanismes d'authentification, d'intégrité des données, de confidentialité et de non répudiation, mais ne s'intéresse pas au contenu sémantique des messages H.225.
Entre ces deux approches, des événements récents ont montré des lacunes sur la sécurité pour laquelle des études et expériences en laboratoire ont conduit à suivre une démarche qui se focalise sur le contenu des messages de signalisation H.225. Ces études et expériences ont permis d'identifier certains champs d'information comme sensibles. Adoptant une approche qui peut être indépendante ou complémentaire de l'utilisation de fonctions H.235 dans les éléments du réseau H.323. Une analyse de ces champs ainsi que de l'enchaînement de messages de signalisation face aux comportements attendus des équipements du réseau ont permis dans le cadre de ces expériences de découvrir des vulnérabilités face auxquelles l'invention a pour but de trouver un remède.
L'invention a pour objet un procédé de sécurisation d'un réseau de communication audiovisuelle dans lequel un premier point d'extrémité échange des messages avec un élément de contrôle. Les messages transmettent des paramètres enregistrés ou à enregistrer dans l'élément de contrôle pour permettre au premier point d'extrémité de communiquer avec au moins un deuxième point d'extrémité enregistré dans l'élément de contrôle. Le procédé est remarquable en ce qu'il comprend une étape d'observation consistant à détecter si un ensemble de paramètres parmi les paramètres transmis dans un message, n'est pas cohérent avec un état courant du destinataire du dit message.
Particulièrement lorsque le destinataire du message est l'élément de contrôle, l'ensemble de paramètres est cohérent si chaque paramètre de l'ensemble ne correspond à aucun paramètre de type et de valeur identiques de point d'extrémité enregistré dans l'élément de contrôle ou s'il existe un ensemble comportant un même nombre de paramètres de types et de valeurs respectivement identiques pour un unique point d'extrémité déjà enregistré dans l'élément de contrôle.
Particulièrement lorsque le destinataire du message est le point d'extrémité, l'ensemble de paramètres n'est pas cohérent si un paramètre de source n'a pas la même valeur que le paramètre de source de l'élément de contrôle auprès duquel le point d'extrémité est enregistré ou si un paramètre désignant le point d'extrémité n'a pas la même valeur que le paramètre de même type connu du point d'extrémité.
Avantageusement, le procédé de sécurisation comprend une étape d'autorisation consistant à détecter pour un paramètre associable à un témoin:
- lorsqu'il existe un témoin transmis, si le paramètre transmis n'est pas de type et de valeur identiques au type et à la valeur d'un attribut de point d'extrémité accrédité par le témoin; et
- lorsque le paramètre transmis est de type identifiant de point d'extrémité, si la valeur du paramètre transmis associable n'appartient pas à une plage de valeurs d'identifiants provisionnée pour le point d'extrémité.
Plus particulièrement, l'ensemble de paramètres devant être cohérent est défini en fonction de la nature du message transmis telle que enregistrement, désenregistrement, localisation, information, admission ou établissement. Pour une nature de message relative à l'enregistrement, le procédé comprend avantageusement une étape d'évaluation consistant à détecter lorsque le message contient un paramètre de type durée de validité d'enregistrement, si ledit paramètre a une valeur inférieure à un seuil prédéfini.
Avantageusement aussi, le procédé de sécurisation comprend une étape de surveillance consistant à détecter si un message de type confirmation reçu par le destinataire n'est pas précédé par un message correspondant de type requête émis par ledit destinataire.
Avantageusement encore, le procédé de sécurisation comprend une étape d'inspection consistant à détecter si une adresse source du message est de valeur différente d'une valeur de paramètre contenu dans le message pour indiquer une adresse de transport vers laquelle émettre une réponse au dit message. - A -
D'autres détails et avantages de l'invention rassortent 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 exemple d'architecture de réseau auquel s'applique l'invention; - La figure 2 illustre des comportements d'élément de contrôle pour des messages d'enregistrement;
- Les figures 3 à 8 illustrent des attaques possibles face aux comportements illustrés par la figure 2;
- La figure 9 illustre des comportements d'élément de contrôle pour des messages de suppression d'enregistrement;
- Les figures 10 et 11 illustrent des attaques possibles face aux comportements illustrés par la figure 9;
- La figure 12 illustre des comportements d'élément de contrôle pour des messages de localisation ou d'information; - Les figures 13 et 14 illustrent des attaques possibles face aux comportements illustrés par la figure 12;
- La figure 15 illustre des comportements d'élément de contrôle et de point d'extrémité pour des messages d'admission et d'établissement;
- Les figures 16 à 18 illustrent des attaques possibles face aux comportements illustrés par la figure 15;
- La figure 19 montre des étapes de procédé de sécurisation relatives à l'enregistrement;
- La figure 20 montre une étape d'observation pour détecter des paramètres incohérents; - La figure 21 montre une étape d'autorisation pour détecter des paramètres qui ne sont pas autorisés;
- La figure 22 montre des étapes de procédé de sécurisation relatives à la suppression d'enregistrement; - La figure 23 montre des étapes de procédé de sécurisation relatives à la localisation et à l'information;
- La figure 24 montre des étapes de procédé de sécurisation relatives à l'admission et à l'établissement. La figure 1 présente un exemple d'architecture de réseau H.323 de façon à décrire des vulnérabilités et attaques associées qui ont pu être démontrées en environnement de laboratoire.
Un réseau 6 de transport par paquets est agencé pour connecter plusieurs points d'extrémités de type H.323 tels que des terminaux 1 , 2 et une passerelle 3 de façon à constituer un réseau de communication audiovisuelle tel qu'un réseau de voix sur IP généralement nommé réseau VoIP. De manière connue, la passerelle 3 permet de connecter sur le réseau de communication audiovisuelle, des terminaux agencés pour se connecter sur d'autres réseaux. Un élément de contrôle 4 (gatekeeper dans la terminologie H.323) est agencé pour enregistrer les points d'extrémité habilités à participer à des communications audiovisuelles. Chaque point d'extrémité 1 , 2, 3, est spécifié respectivement par une adresse de transport RA1 , RA2, RA3 pour son canal nommé RAS qui porte trois fonctions: enregistrement, admission et statut, une adresse de transport CSA1 , CSA2, CSA3 pour son canal CS de signalisation d'appel et un ou plusieurs identifiants ALI AS 1 , ALIAS2, ALIAS3. On indique que le canal RAS prévu en particulier pour des messages de type "RRQ", "URQ", "ARQ", "LRQ", "IRQ", utilise généralement un protocole de transport en mode non connecté tel qu'UDP. Le canal CS prévu en particulier pour des messages de type "Setup", "Alerting", "Connect", "Release Corn", utilise généralement un protocole de transport en mode connecté tel que TCP. Un point d'extrémité tel que par exemple ici représentés le terminal 1 et la passerelle 3, peut aussi être doté respectivement d'un témoin TOKEN1 , TOKEN3 selon la recommandation H.235, pour en renforcer l'identification. Le réseau 6 peut contenir un ou plusieurs éléments de filtrage non représentés qui sont prévus pour surveiller les messages de signalisation échangés entre les points d'extrémité 1 , 2, 3 et l'élément de contrôle 4, en conformité avec les recommandations H.323, H.225 et H.235. Le procédé expliqué par la suite, permet de sécuriser le réseau face à un attaquant 5 qui simule un terminal H.323. On suppose que l'attaquant 5 est capable de générer à sa guise des messages de signalisation en dehors de toute contrainte temporelle, conformes aux Recommandations H.323, H.225 et H.235, tant du point de vue du format que des champs d'information utilisés. L'attaquant 5 peut positionner les champs d'information des messages de signalisation aux valeurs nécessaires pour conduire son attaque, peut faire parvenir les messages de signalisation qu'il génère à l'élément de contrôle 4 en contournant le cas échéant les entités de filtrage déployées dans le réseau de transport. Les moyens utilisés par l'attaquant 5 pour contourner les entités de filtrage du réseau sortent du cadre de l'invention. L'attaquant connaît au moins une plage d'identifiants (ALIAS) et une plage d'adresses de transport dans lesquelles sont enregistrés les points d'extrémités. Dans le cas le plus courant, il s'agira pour les identifiants d'une plage de numéros de téléphone et ou une plage d'adresses IP dans lesquelles sont enregistrés les points d'extrémités. Le procédé par lequel l'attaquant arrive à connaître ces informations sort du cadre de l'invention.
Sur la base de ces hypothèses et des comportements décrits à présent, des études et expériences en laboratoire ont permis de démontrer une faisabilité d'attaques pour au moins un élément de réseau H.323. La figure 2 présente un exemple de transitions et étapes possibles d'un élément de contrôle H323 (GateKeeper) à seule fin d'illustrer des comportements conformes aux préconisations H323, H225 et H235 pour des messages de demande d'enregistrement RRQ (Registration ReQuest), des messages de confirmation d'enregistrement RCF (Registration ConFirm) et des messages de refus d'enregistrement RRJ (Registration ReJect).
L'enregistrement est le procédé par lequel un point d'extrémité informe l'élément de contrôle de ses adresses de transport et du(des) identifiant(s) (ALIAS) associé(s) à ces adresses. Un comportement C1 de l'élément de contrôle est illustré par une transition 12 validée par une réception de message RRQ censé provenir du point d'extrémité. Dans une étape 13 activée par une validation de la transition 12, l'élément de contrôle analyse particulièrement des valeurs reçues CSAr, RAr, ALIASr, TTLr et KALr dans les champs suivants du message RRQ. Dans le message RRQ:
- un champ CSA (CaII Signal Address) est destiné à contenir une adresse de transport utilisée pour le canal de signalisation CS (CaII Signalling) du point d'extrémité;
- un champ RA (Ras Address) est destiné à contenir une adresse de transport utilisée pour le canal RAS servant les fonctions d'enregistrement, d'admission et de statut (Registration Admission Status);
- un champ ALIAS est destiné à contenir un ou plusieurs identifiants du point d'extrémité tel qu'un numéro de téléphone, un identifiant e164, un identifiant
H.323, une adresse de messagerie électronique ou autre;
- un champ TTL (Time To Live) est destiné à contenir une durée de validité de l'enregistrement. Lorsque la durée de l'enregistrement dépasse la durée de validité, l'élément de contrôle considère que l'enregistrement a expiré tel qu'illustré par une transition 14 et une étape 15;
- un champ KAL (Keep ALive) est destiné à être positionné à faux, par exemple 0, lorsque le point d'extrémité se considère non encore enregistré auprès de l'élément de contrôle et à vrai, par exemple 1 , pour un maintien de l'enregistrement. Le maintien d'enregistrement résulte d'une ré-émission de messages RRQ par le point d'extrémité vers l'élément de contrôle, avant expiration de la durée de validité d'enregistrement.
Le procédé d'enregistrement peut être répété périodiquement par le point d'extrémité. Un comportement C2 de l'élément de contrôle est illustré par une étape 11 dans laquelle l'élément de contrôle est constamment à l'écoute de réceptions de messages RRQ.
Les messages envoyés sur le canal RAS par l'élément de contrôle vers le point d'extrémité doivent être à destination de l'adresse indiquée par le champ RA du message RRQ et non à destination de l'adresse source AS d'où provient le message RRQ ou tout autre message. Un comportement C3 de l'élément de contrôle à ce sujet, est illustré par une étape 19 dans laquelle l'élément de contrôle envoie un message RCF à destination de l'adresse RAr analysée en étape 13 après avoir positionné les valeurs enregistrées RAe et TTLe aux valeurs reçues RAr et TTLr dans la mesure où il existe une valeur TTLr acceptée par l'élément de contrôle. Le comportement C3 de l'élément de contrôle à ce sujet, est aussi illustré par une étape 27 dans laquelle l'élément de contrôle envoie un message RRJ à destination de l'adresse RAr analysée en étape 13.
Un comportement C4 de l'élément de contrôle consiste à répondre par un message RCF lorsque le message RRQ reçu désigne la même adresse de transport pour le canal CS et le même identifiant (ALIAS) qu'un point d'extrémité déjà enregistré auprès de lui. Le comportement C4 est illustré par un déclenchement de l'étape 19 à la suite de transitions 16, 18 ou à la suite de transitions 20, 22. La transition 16 est validée lorsque l'élément de contrôle découvre un enregistrement contenant une valeur ALIASe égale à la valeur reçue ALIASr. La transition 18 est validée lorsque l'élément de contrôle constate que la valeur reçue CSAr est égale à une valeur enregistrée CSAe dans le même enregistrement que celui contenant la valeur ALIASe. La transition 20 est validée lorsque l'élément de contrôle découvre un enregistrement contenant une valeur CSAe égale à la valeur reçue CSAr. La transition 22 est validée lorsque l'élément de contrôle constate que la valeur reçue ALIASr est égale à une valeur enregistrée ALIASe dans le même enregistrement que celui contenant la valeur CSAe. Selon un comportement C5, si l'élément de contrôle reçoit un message
RRQ dont au moins un alias désigne un point d'extrémité déjà enregistré auprès de lui, mais dont l'adresse de transport sur le canal de signalisation contenue dans le RRQ ne correspond pas à ce point d'extrémité, l'élément de contrôle peut confirmer la requête ou retourner un message RRJ en indiquant qu'il s'agit d'un alias dupliqué. Le comportement C5 est illustré par un déclenchement à la suite de transitions 16, 24, de l'étape 27 sur validation d'une transition 26 ou de l'étape 19 suite à une validation d'une transition 28. La transition 16 est validée lorsque l'élément de contrôle découvre un enregistrement contenant une valeur ALIASe égale à la valeur reçue ALIASn. La transition 24 est validée lorsque l'élément de contrôle constate que la valeur reçue CSAr est différente de la valeur enregistrée CSAe dans le même enregistrement que celui contenant la valeur ALIASe. La transition 26 est validée à condition que l'élément de contrôle refuse toute valeur reçue CSAr pour un enregistrement contenant une valeur CSAe différente. La transition 28 est validée en absence d'une telle condition par exemple pour permettre une migration en remplaçant dans une étape 29, la valeur enregistrée CSAe par la valeur reçue CSAr avant activation de l'étape 19. Selon un comportement C6, si l'élément de contrôle reçoit un message
RRQ dont l'adresse de transport pour le canal de signalisation (CSAr) désigne un point d'extrémité déjà enregistré auprès de lui, mais que l'identifiant (ALIASn) contenu dans le message RRQ ne correspond pas à ce point d'extrémité, alors l'identifiant spécifié dans le message RRQ doit remplacer celui précédemment enregistré pour ce point d'extrémité. Ce comportement ne s'applique qu'au cas où le message RRQ n'est pas additif. Le comportement C6 est illustré par un déclenchement à la suite de transitions 20, 30, d'une étape 33 sur validation d'une transition 32 ou d'une étape 35 sur validation d'une transition 34. La transition 30 est validée lorsque l'élément de contrôle découvre un enregistrement contenant une valeur ALIASe différente de la valeur reçue ALIASr. La transition 32 est validée lorsque le message RRQ est de type additif. La transition 34 est validée lorsque le message RRQ n'est pas de type additif. Dans l'étape 33 la valeur reçue ALIASn est ajoutée à la liste des valeurs enregistrées ALIASe. Dans l'étape 35 la valeur reçue ALIASr remplace la valeur enregistrée ALIASe. Un point d'extrémité peut envoyer un message RRQ en spécifiant une valeur de durée de validité TTL (Time To Live). Après réception du message RCF et écoulement du délai TTL, un comportement C7 de l'élément de contrôle consiste à considérer que l'enregistrement du point d'extrémité a expiré et supprime son enregistrement. Le comportement C7 est illustré par l'étape 15 déclenchée à la suite de la transition 14 validée par chaque dépassement temporel de délai TTL attribué à un enregistrement identifié par une clé EPID (EndPoint Identifier). Dans l'étape 15, la totalité de l'enregistrement identifié est supprimé, ce qui provoque généralement un envoi de message URQ vers le point d'extrémité qui est alors contraint d'acquiter la demande de désenregistrement. On indique que la durée de validité TTL peut aussi être fixée à l'initiative de l'élément de contrôle et que l'élément de contrôle peut refuser une valeur TTL demandée par le point d'extrémité. Selon un comportement C8, un premier enregistrement de point d'extrémité est fait en positionnant le champ KAL (keepAlive) à faux et les demandes de maintien d'enregistrement sont faites en positionnant le champ KAL à vrai. Le comportement C8 est illustré par une transition 38 validée lorsque la valeur KALr reçue dans le message RRQ est positionnée à faux. La transition 38 active une étape 39 dans laquelle l'élément de contrôle génère une valeur EPIDe pour identifier un nouvel enregistrement destiné à mémoriser les valeurs reçues CSAr et ALIASr, normalement détectées absentes de tout enregistrement précédent par validation d'une transition 36. La transition 36 est typiquement validée lorsqu'il n'existe aucune valeur enregistrée ALIASe et aucune valeur enregistrée CSAe respectivement égale à la valeur reçue ALIASn et à la valeur reçue CSAr. La clé d'identité EPID sert ensuite au point d'extrémité pour identifier un enregistrement précédent auprès de l'élément de contrôle, particulièrement lorsque le champ KAL est positionné à vrai. L'enregistrement est confirmé au point d'extrémité par envoi d'un message RCF en étape 19 dans laquelle la valeur enrgistrée RAe et éventuellement la valeur enregistrée TTLe, sont mises respectivement à des valeurs égales aux valeurs reçues RAr et TTLr dans le message RRQ.
Les comportements C1 à C8 sont vulnérables à des attaques telles que celles illustrées par les figures 3 à 8. En référence à la figure 3, une transition 40 est validée lorsqu'un attaquant décide de mener une attaque A1 visant à connaître les alias de points d'extrémité enregistrés sur l'élément de contrôle. Dans une étape 41 activée par validation de la transition 40, l'attaquant envoie vers l'élément de contrôle GK (Gatekeeper), un message RRQ dont le champ RA contient une valeur Rat égale à l'adresse RA(attaquant) du canal RAS de l'attaquant, le champ CSA contient une valeur CSAt égale à l'adresse CSA(attaquant) du canal CS de l'attaquant, et le champ ALIAS contient une valeur ALIASt qui appartient à la plage d'alias gérée par l'élément de contrôle GK. D'après les comportements C3 et C5, l'attaquant reçoit en retour un message RRJ ou RCF. La réception d'un message RRJ avec la cause "duplicateAlias" signifiant que l'alias est déjà enregistré sur l'élément de contrôle, valide une transition 42 qui active une étape 43 dans laquelle l'attaquant constate que la valeur ALIASt est égale à une valeur d'alias de point d'extrémité enregistré. La réception d'un message RCF validant une transition 44a ou d'un message RRJ avec une cause différente de "duplicateAlias" validant une transition 44 active une étape 45 dans laquelle l'attaquant constate que l'alias transmis n'était pas enregistré sur le l'élément de contrôle. Ainsi, en balayant toute la plage d'alias par envois successifs de messages RRQ, l'attaquant connaît les alias des points d'extrémités enregistrés sur l'élément de contrôle. On indique que la transition 42 peut aussi être validée par une absence de réception de message en provenance de l'élément de contrôle, par exemple à expiration d'un certain délai. En effet, si l'élément de contrôle envoie un message RCF vers le point d'extrémité régulier, ceci est interprétable en étape 43 comme une existence de valeur enregistrée d'identifiant ALIASe égale à la valeur transmise ALIASt. L'attaquant peut adapter ses émissions de messages RRQ à une fréquence suffisamment faible pour se noyer dans le flot régulier des messages reçus par l'élément de contrôle. Pour augmenter la furtivité de l'attaque, le balayage peut se faire aléatoirement dans la plage d'alias ciblée.
En référence à la figure 4, une transition 46 est validée lorsqu'un attaquant décide de mener une attaque A2 visant à connaître l'adresse d'un point d'extrémité dont l'attaquant connaît l'alias. Pour mener l'attaque A2, l'attaquant a préalablement obtenu connaissance de l'alias d'au moins un point d'extrémité enregistré, par exemple au moyen de l'attaque A1. Dans une étape 47 activée à la suite de la transition 46, l'attaquant envoie vers l'élément de contrôle GK (gatekeeper) un message RRQ dont le champ RA contient une valeur Rat égale à l'adresse RA(attaquant) du canal RAS de l'attaquant, le champ CSA contient une valeur CSA4 qui appartient à la plage d'adresses pour le canal de signalisation gérée par l'élément de contrôle GK, le champ ALIAS contient une valeur ALIASt égale à la valeur ALIASe connue d'un point d'extrémité enregistré. D'après les comportements C3, C4 et C5, l'attaquant reçoit en retour un message RRJ validant une transition 48 ou un message RCF validant une transition 50b. La transition 48 active une étape 49 dans laquelle l'attaquant constate que l'adresse mise dans le champ CSA n'est pas celle du point d'extrémité enregistré et le processus de recherche est réitéré avec une nouvelle adresse de la plage d'adresses de canal de signalisation gérée par l'élément de contrôle. La transition 50b active une étape 51 dans laquelle l'attaquant constate que l'adresse mise dans le champ CSA est bien celle du point d'extrémité enregistré et marque la fin du processus de recherche. Si le comportement de l'élément de contrôle n'est pas conforme à C3, il se peut que le RCF soit envoyé vers le point d'extrémité enregistré et que le terminal attaquant ne reçoive aucun message en retour du RCF. Cette absence de réponse validant une transition 50 est assimilable à une réception de message RCF qui a pour effet d'activer l'étape 51. Ainsi à la fin de l'attaque, l'attaquant connaît l'adresse de transport pour le canal CS correspondant à l'alias du point d'extrémité enregistré. Dans le cas où un message RCF est reçu, l'attaquant acquiert de plus la connaissance de la clé d'identité EPIDe du point d'extrémité enregistré. De même que pour l'attaque A1 , l'attaquant peut adapter ses émissions de messages RRQ à une fréquence suffisamment faible pour se noyer dans le flot régulier des messages reçus par l'élément de contrôle et le balayage peut se faire aléatoirement dans la plage d'adresses ciblée.
En référence à la figure 5, une transition 52 est validée lorsqu'un attaquant décide de mener une attaque A3 visant à désenregistrer un point d'extrémité régulier de l'élément de contrôle d'une première manière. Pour mener l'attaque A3, l'attaquant a préalablement obtenu connaissance de l'alias et de l'adresse de transport pour le canal de signalisation CS d'au moins un point d'extrémité enregistré, par exemple au moyen des attaques A1 et A2. Dans une étape 53 activée à la suite de la transition 52, l'attaquant envoie vers l'élément de contrôle GK (gatekeeper) un message RRQ non additif dont le champ RA contient une valeur Rat égale à l'adresse RA(attaquant) du canal RAS de l'attaquant, le champ CSA contient une valeur CSAt égale à la valeur CSAe que l'attaquant connaît à propos d'un point d'extrémité enregistré, le champ ALIAS contient une valeur ALIASt égale à une valeur d'alias non enregistrée sur l'élément de contrôle ou aucune valeur d'identifiant lorsque l'élément de contrôle accepte des messages RRQ avec un champ ALIAS vide. D'après les comportements C3 et C6, l'attaquant reçoit un message RCF de confirmation d'enregistrement signifiant que le nouvel alias donné par l'attaquant dans le RRQ a remplacé l'alias du point d'extrémité régulier. Le message RCF contenant de plus la nouvelle valeur de clé EPID pour cet enregistrement, valide une transition 56 qui active une étape 57 qui permet à l'attaquant de prendre connaissance d'interférer à sa guise avec l'enregistrement. Dans le cas où le comportement de l'élément de contrôle n'est pas conforme à C3, Ie message RCF n'est pas reçu par l'attaquant, mais le résultat est le même du point de vue de l'attaque, à savoir celui indiqué dans l'étape 55 validée par une transition 54 autant que par la transition 56: l'alias et la valeur de la clé EPID que détient le point d'extrémité régulier, ne sont plus valides et le point d'extrémité régulier doit procéder à un nouvel enregistrement.
En référence à la figure 7, une transition 58 est validée lorsqu'un attaquant décide de mener une attaque A4 visant à désenregistrer un point d'extrémité régulier de l'élément de contrôle d'une seconde manière. Pour mener l'attaque A4, l'attaquant a préalablement obtenu connaissance de l'alias et de l'adresse de transport pour le canal de signalisation d'au moins un point d'extrémité enregistré, par exemple au moyen des attaques A1 et A2. Dans une étape 59 activée à la suite de la transition 58, l'attaquant envoie vers l'élément de contrôle GK (gatekeeper) un message RRQ dont le champ RA contient une valeur Rat égale à l'adresse RA(attaquant) du canal RAS de l'attaquant, le champ CSA contient une valeur CSAt égale à la valeur CSAe et le champ ALIAS contient une valeur ALIASt égale à la valeur d'alias ALIASe que l'attaquant connaît à propos d'un point d'extrémité enregistré sur l'élément de contrôle. De plus, le champ TTL dans le message RRQ est positionné à une valeur de délai ε faible, typiquement inférieure à la durée normale d'enregistrement du système et le champ KAL est positionné à vrai pour indiquer qu'il s'agit d'un maintien d'enregistrement. D'après les comportements C2, C4, C7 et C8 l'élément de contrôle accepte cette demande de maintien d'enregistrement et à l'expiration du délai ε considère que le point d'extrémité est désenregistré. Indépendamment d'une réception ou non de message RCF selon que l'élément de contrôle est conforme ou non au comportement C3 l'attaquant sait qu'à l'expiration du délai ε validant une transition 60, le point d'extrémité régulier est désenregistré automatiquement par l'élément de contrôle. Parallèlement à l'activation d'une étape 61 à la suite de la transition 60, l'élément de contrôle envoie généralement un message de désenregistrement (URQ) vers le point d'extrémité régulier. A l'issu de l'attaque le point d'extrémité régulier doit procéder à un nouvel enregistrement.
En référence à la figure 8, une transition 62 est validée lorsqu'un attaquant décide de mener une attaque A5 visant à usurper l'identité d'un point d'extrémité régulier. Une première phase préalable consiste à déterminer les paramètres ALIAS et CSA d'un point d'extrémité régulier en appliquant les procédés décrits à propos des attaques A1 et A2, ou tout autre procédé conduisant à un résultat identique. Une seconde phase préliminaire à l'attaque A5 consiste à provoquer un désenregistrement temporaire du point d'extrémité régulier en appliquant les procédés décrits à propos des attaques A3 ou A4, ou tout autre procédé conduisant à un résultat identique. On entend par temporaire, le fait que le désenregistrement ne dure en fait que jusqu'au moment où le point d'extrémité régulier se ré-enregistre. Dans une étape 63 activée à la suite de la transition 62, l'attaquant envoie vers l'élément de contrôle GK un message RRQ dont le champ RA contient une valeur Rat égale à l'adresse RA(attaquant) du canal RAS de l'attaquant, le champ CSA contient une valeur CSAt égale à la valeur de l'adresse de transport de l'attaquant CSA(Attaq) et le champ ALIAS contient une valeur ALIASt égale à la valeur d'identifiant ALIASde du point d'extrémité dont l'attaquant cherche à usurper l'identité. Une transition 64 validée par une réception de message RCF active une étape 65 qui fait savoir à l'attaquant qu'il est à présent enregistré auprès de l'élément de contrôle sous l'alias du point d'extrémité régulier. Le point d'extrémité régulier ne peut alors plus s'enregistrer puisque son alias d'identification est désormais attribué au terminal attaquant. Le terminal attaquant peut ensuite émettre ou recevoir des appels à la place du point d'extrémité régulier.
En référence à la figure 6, une transition 66 est validée lorsqu'un attaquant décide de mener une attaque A6 visant à créer une désynchronisation entre les états d'un élément de contrôle et d'un point d'extrémité. Cette attaque s'applique particulièrement aux réseaux H.323 dans lesquels les points d'extrémités procèdent à un maintien d'enregistrement par envoi périodique de messages RRQ. Une première phase préalable consiste à déterminer les paramètres ALIAS et CSA d'un point d'extrémité régulier, en appliquant les procédés décrits à propos des attaques A1 et A2, ou tout autre procédé conduisant à un résultat identique. Une seconde phase préliminaire à l'attaque consiste à provoquer un désenregistrement temporaire du point d'extrémité régulier, en appliquant le procédé décrit à propos de l'attaque A4, ou tout autre procédé conduisant à un résultat identique. Dans une étape 67 activée à la suite de la transition 66, l'attaquant envoie un nouveau message RRQ dont les champs ALIAS et CSA contiennent les valeurs ALIASe et CSAe du point d'extrémité régulier, et le champ KAL est positionné à faux pour signifier qu'il s'agit d'un nouvel enregistrement. Selon le comportement C4, l'élément de contrôle accepte ce nouvel enregistrement et retourne un message RCF vers le point d'extrémité régulier ou vers l'attaquant, en fonction du positionnement du champ RA dans le message RRQ et la conformité de l'élément de contrôle au comportement C3. Lorsque le point d'extrémité régulier essaie de se ré-enregistrer, son action échoue car il a déjà été ré-enregistré par l'attaquant. L'attaquant réalise donc un désenregistrement puis un ré-enregistrement du point d'extrémité régulier, avant que le point d'extrémité régulier ne l'ait fait lui-même. Il en résulte que l'élément de contrôle est dans un état où il attend du point d'extrémité régulier des messages RRQ avec une valeur KAL à vrai, puisqu'il a déjà reçu le message RRQ envoyé par l'attaquant avec une valeur KAL à faux. De son côté, le point d'extrémité régulier essaie de se ré-enregistrer en envoyant des messages RRQ avec une valeur KAL à faux, et donc ne parvient pas à le faire.
La figure 9 présente un exemple de transitions et étapes possibles d'un élément de contrôle H323 (GateKeeper) à seule fin d'illustrer des comportements conformes aux préconisations H323, H225 et H235 pour des messages de demande de désenregistrement URQ (Unregistration ReQuest), des messages de confirmation de désenregistrement UCF (Unregistration ConFirm) et des messages de refus de désenregistrement URJ (Unregistration ReJect).
Un point d'extrémité peut à tout moment envoyer un message URQ vers l'élément de contrôle afin de supprimer son enregistrement auprès de cet élément de contrôle. Un comportement C9 de l'élément de contrôle est illustré par une transition 68 validée par une réception de message URQ censé provenir du point d'extrémité. Dans une étape 69 activée par une validation de la transition 68, l'élément de contrôle analyse particulièrement des valeurs reçues CSAr, {ALIAS,}, et EPIDr dans les champs correspondants du message URQ.
Selon un comportement C10, l'élément de contrôle peut à tout moment supprimer l'enregistrement d'un point d'extrémité, par exemple à expiration de la valeur TTL de l'enregistrement identifié par la clé EPID tel qu'illustré par une transition 70 qui active une étape 71 dans laquelle un message URQ est envoyé à destination de l'adresse de transport RA contenue dans l'enregistrement référencé EPID. Le point d'extrémité est contraint d'accepter la suppression d'enregistrement émise par l'élément de contrôle et doit lui répondre par un message UCF tel que celui qui valide une transition 72 pour activer une étape 73 dans laquelle l'enregistrement identifié EPID est supprimé.
Si un point d'extrémité envoie une demande URQ vers un élément de contrôle contenant une liste de champs {ALIAS,} et que l'élément de contrôle accepte la demande, il ne doit supprimer de l'enregistrement que les identifiants spécifiés dans le message URQ. Ce comportement C11 est illustré par une transition 74 qui active une étape 75 dans laquelle les identifiants de la liste {ALIASr} sont retirés de la liste {ALIASe} des identifiants enregistrés pour ce point d'extrémité et un message UCF est envoyé au point d'extrémité. L'égalité des deux listes valide une transition 78 qui active une étape 77 dans laquelle un message UCF est envoyé à destination de l'adresse de transport RA contenue dans l'enregistrement référencé par la clé EPID.
Si un point d'extrémité envoie un message URQ vers l'élément de contrôle ne contenant pas de champs ALIAS et ne contenant pas non plus les champs endpointAliasPattern et supportedPrefixes tels que définis dans la norme H.225, l'élément de contrôle doit supprimer tous les enregistrements d'alias relatifs à ce point d'extrémité. Ce comportement C12 est illustré par une transition 76 qui active l'étape 77. L'étape 73 alors activée avec l'étape 77 suite à validation de la transition 76 ou de la transition 78 a pour effet de désenregistrer le point d'extrémité.
De même, si l'élément de contrôle envoie un message URQ vers un point d'extrémité ne contenant pas de champ ALIAS, un comportement C13 implique le désenregistrement de tous les alias identifiant ce point d'extrémité, et donc du point d'extrémité lui-même.
Lorsqu'un élément de contrôle envoie un message URQ vers un point d'extrémité, un comportement C14 dispense l'élément de contrôle de compléter le champ EPID (endpointldentifier) du message URQ. Les comportements C9 à C14 sont vulnérables à des attaques telles que celles illustrées par les figures 10 et 11.
En référence à la figure 10, une transition 80 est validée lorsqu'un attaquant décide de mener une attaque A7 visant à désenregistrer un point d'extrémité auprès de l'élément de contrôle d'une première façon. Dans une phase préliminaire à l'attaque A7, l'attaquant a pris connaissance des valeurs de l'adresse de transport CSA pour le canal CS et du paramètre EPID du point d'extrémité qu'il souhaite désenregistrer. Cette connaissance peut être acquise en menant au préalable une des attaques A1 à A6, ou par tout autre procédé conduisant à un résultat identique. La transition 80 active une étape 81 dans laquelle l'attaquant envoie vers l'élément de contrôle (GK) un message URQ dont les valeurs de paramètres CSAt et EPIDt sont égales aux valeurs CSAe et EPID(PE) précédemment déterminées, et ne contenant pas de champ ALIAS. D'après les comportements C9 et C12, l'élément de contrôle accepte la demande de désenregistrement et envoie un message UCF vers le point d'extrémité désigné par les paramètres CSA et EPID. On note que l'attaquant n'a pas besoin de compléter le champ ALIAS du message URQ du fait du comportement C12. Le résultat est que le point d'extrémité est temporairement désenregistré de l'élément de contrôle. Ce résultat est similaire à celui des attaques A3 et A4 et peut être suivi d'une attaque d'usurpation d'identité avant que le terminal régulier n'ait eu le temps de s'enregistrer de nouveau.
En référence à la figure 11 , une transition 82 est validée lorsqu'un attaquant décide de mener une attaque A8 visant à désenregistrer un point d'extrémité d'une seconde façon. Dans une phase préliminaire à l'attaque A8, l'attaquant a pris connaissance des valeurs de l'adresse de transport CSA pour le canal CS et de l'adresse de transport RA pour le canal RAS du point d'extrémité qu'il souhaite désenregistrer. Cette connaissance peut être acquise en menant au préalable une des attaques A1 à A6, ou par tout autre procédé conduisant à un résultat identique. La transition 82 active une étape 83 dans laquelle l'attaquant envoie vers le point d'extrémité (PE) un message URQ dont le paramètre CSA a pour valeur CSAt, la valeur CSAe précédemment déterminée, et ne contenant ni de champ ALIAS, ni de champ EPID. D'après les comportements C10, C13 et C14, le point d'extrémité accepte la demande de désenregistrement et renvoie un message UCF vers l'élément de contrôle auprès duquel il était enregistré. En effet, les comportements C13 et C14 dispensent l'attaquant de compléter les champs ALIAS et EPID du message URQ. Le résultat est que le point d'extrémité est désen registre, et doit initier une nouvelle demande d'enregistrement auprès de l'élément de contrôle. Si cette attaque est itérée en un temps très court vers un grand nombre de points d'extrémités, elle entraîne un afflux de messages vers l'élément de contrôle (GK) pouvant provoquer la mise hors service de celui-ci. De plus, suivant le fonctionnement de l'élément de contrôle, l'attaque A8 peut créer un état de désynchronisation entre le point d'extrémité et l'élément de contrôle puisque ce dernier reçoit une nouvelle demande d'enregistrement provenant d'un point d'extrémité qu'il considère comme étant déjà enregistré.
La figure 12 présente un exemple de transitions et étapes possibles d'un élément de contrôle H323 (GateKeeper) et d'un point d'extrémité H323 (Endpoint) à seule fin d'illustrer des comportements conformes aux préconisations H323, H225 et H235 pour des messages de demande de localisation LRQ (Location ReQuest), des messages de confirmation de localisation LCF (Location ConFirm) et des messages de refus de localisation LRJ (Location ReJect) ainsi que des messages de demande d'information IRQ (Information ReQuest) et des messages de réponse IRR (Information ReQuest Response).
Un point d'extrémité ou un élément de contrôle peut à tout moment envoyer un message LRQ vers un élément de contrôle afin d'obtenir les informations de localisation d'un point d'extrémité tiers dont il connaît au moins un alias. Les informations de localisation retournées par l'élément de contrôle incluent en particulier des valeurs de paramètres CSA, RA et Dl. Le champ Dl est destiné à contenir un ou plusieurs identifiants de point d'extrémité de destination d'une communication audiovisuelle tels que par exemple un numéro de téléphone, un identifiant e164, un identifiant H.323, une adresse de messagerie électronique ou autre. Un comportement C15 d'élément de contrôle est illustré par une transition 84 validée par une réception de message LRQ censé provenir d'un point d'extrémité ou d'un autre élément de contrôle réguliers. Dans une étape 85 activée par une validation de la transition 84, l'élément de contrôle analyse des valeurs reçues ALIASr, et particulièrement RPAr dans un champ RPA (RePIy Address) du message LRQ qui est destiné à contenir une adresse réseau d'entité vers laquelle doit être retournée une réponse au message LRQ ou à un message IRQ. Dans une étape 89 activée par une validation de transition 88 à la suite de l'étape 85, l'élément de contrôle envoie à destination de l'adresse RPAr, un message LCF contenant des valeurs CSAe, RAe et Dle enregistrées pour le point d'extrémité reconnu par son identifiant ALIASe égal à la valeur reçue ALIASr lors d'une validation de transition 88. La valeur Dle est transmise dans le champ de paramètre Dl (Destination Info) dans le cas d'un message LRQ ou ARQ vu ultérieurement ou (Destination Address) dans le cas d'un message de type établissement d'appel habituellement nommé Setup et vu ultérieurement.
Un élément de contrôle recevant un message LRQ désignant un point d'extrémité qui n'est pas enregistré auprès de lui doit répondre en retournant un message LRJ lorsque le message LRQ a été reçu sur le canal RAS de l'élément de contrôle. Ce comportement C16 est illustré par la transition 86 qui active une étape 87 pour envoi du message de refus de localisation LRJ. La transition 86 est par exemple validée lorsque aucune valeur d'identifiant enregistrée ALIASe ne correspond à la valeur reçue ALIASr.
Un comportement C17 d'élément de contrôle recevant une demande LRQ consiste à répondre vers l'adresse réseau désignée par le paramètre RPA du message LRQ, qu'il s'agisse d'une réponse LCF ou LRJ.
Conformément à un comportement C18, un élément de contrôle peut à tout moment demander des informations d'usage à un point d'extrémité en lui envoyant un message IRQ qui spécifie dans des champs CRV et CID des valeurs correspondant à un appel recherché. Le champ CRV (CaII Référence Value) est destiné à contenir une référence d'appel et le champ CID (CaII Identifier) est destiné à contenir un identifiant d'appel. Pour plus de détails, on peut utilement se reporter au normes H.323 et H.225. Une réception de message IRQ par un point d'extrémité y valide une transition 90 qui active une étape 91 dans laquelle le point d'extrémité prend connaissance de valeurs CRVr, CIDr et RPAr reçues dans le message IRQ. Lorsqu'un élément de contrôle adopte un comportement C19 pour connaître des informations d'usage relatives à un point d'extrémité pour tous les appels en cours, il lui suffit de positionner le champ CRV à 0. Dans ce cas, la valeur du champ CID est non significative et peut être positionnée également à 0. La valeur nulle CRVr valide alors une transition 92 dans le point d'extrémité. Une transition 96 validée par chaque présence d'un appel en cours, active alors une étape 97 dans laquelle le point d'extrémité fourni les informations relatives à l'appel en cours.
Lorsqu'un point d'extrémité reçoit une demande IRQ avec le champ CRV positionné à 0 alors qu'une absence d'appel en cours valide une transition 94, le point d'extrémité doit adopter un comportement C20 qui consiste à répondre au message IRQ en fournissant dans une étape 95, toutes les autres informations dont il dispose en dehors des informations d'appel. Lorsqu'un point d'extrémité reçoit une demande IRQ avec le champ CRV positionné à une valeur non nulle qui valide une transition 98, le point d'extrémité répond au message IRQ en fournissant dans une étape 99, les informations dont il dispose relativement à l'appel identifié par la valeur CIDr reçue.
Les étapes 95 et 97 mettent aussi en évidence un comportement C21 selon lequel un point d'extrémité recevant une demande IRQ doit répondre vers l'adresse réseau désignée par le paramètre RPA du message IRQ, et non vers l'adresse source (AS) du paquet IRQ.
En référence à la figure 13, une transition 100 est validée lorsqu'un attaquant décide de mener une attaque A9 visant à récupérer les informations sur les points d'extrémités enregistrés auprès de l'élément de contrôle. La transition 100 active une étape 101 dans laquelle l'attaquant envoie un message LRQ vers l'élément de contrôle avec le champ Dl positionné à une valeur d'alias ALIASt contenue dans la plage d'alias {ALIAS} gérée par l'élément de contrôle (GK), et où le champ RPA désigne l'adresse RAt de l'attaquant. D'après les comportements C15, C16 et C17, l'attaquant reçoit en retour un message LRJ qui valide une transition 102 ou un message LCF qui valide une transition 104. La réception d'un message LRJ signifie dans une étape 103 que cet alias n'est pas enregistré auprès de l'élément de contrôle. La réception d'un message LCF indique dans une étape 105 que cet alias est enregistré auprès de l'élément de contrôle et fournit en plus des informations sensibles sur le point d'extrémité, telles que les valeurs de paramètres CSAe, RAe. En balayant toute la plage d'alias par envois successifs de messages LRQ, l'attaquant peut déterminer les points d'extrémité enregistrés auprès de l'élément de contrôle et les informations d'enregistrement associées. Le résultat de l'attaque est très similaire à celui des attaques A1 et A2 à ceci près que, contrairement au message RCF, le message LCF ne contient pas d'information de type EPID. On notera que l'adresse source (AS) pour l'émission du paquet LRQ peut être celle de l'attaquant lui-même ou celle d'une entité H.323 en provenance de laquelle l'élément de contrôle accepterait de recevoir une demande LRQ. Le second cas suppose que l'attaquant sait contourner les entités de filtrage réseau et donc qu'il parvient à usurper l'identité d'une entité régulière lors de l'envoi du message LRQ.
En référence à la figure 14, une transition 106 est validée lorsqu'un attaquant décide de mener une attaque A10 visant à récupérer les informations d'usage d'un point d'extrémité. La transition 106 active une étape 107 dans laquelle l'attaquant envoie un message IRQ vers le point d'extrémité PE visé par son adresse dans le champ RA, avec les champs CRV et CID positionnés à 0 et dont le champ RPA désigne l'adresse de l'attaquant. D'après les comportements C18 et C19, le point d'extrémité doit accepter le message IRQ. Dans le cas où il y a un appel en cours, ou même s'il n'y a pas d'appel en cours d'après C20, le point d'extrémité doit répondre à cette demande IRQ en renvoyant un message IRR vers l'adresse spécifiée dans le champ RPA d'après C21 , c'est-à-dire vers l'attaquant. Suite à la réception du message IRR validant une transition 108, l'attaquant connaît des informations sensibles sur le point d'extrémité, telles que les paramètres CSA(PE), RA(PE), ALIAS(PE) et EPID(PE). Le résultat de l'attaque A10 est très similaire à celui des attaques A1 et A2, et de plus l'attaque A10 peut être réitérée vers l'ensemble des points d'extrémité enregistrés auprès de l'élément de contrôle. On notera que l'adresse source (AS) pour l'émission du paquet IRQ peut être celle de l'attaquant lui-même ou celle d'une entité H.323 en provenance de laquelle le point d'extrémité accepterait de recevoir une demande IRQ, typiquement l'élément de contrôle dans lequel le point d'extrémité est enregistré. Le second cas suppose que l'attaquant sait contourner les entités de filtrage réseau et donc qu'il parvient à usurper l'identité de l'élément de contrôle lors de l'envoi du message IRQ.
La figure 15 présente un exemple de transitions et étapes possibles d'un élément de contrôle H323 (GateKeeper) et d'un point d'extrémité H323 (Endpoint) à seule fin d'illustrer des comportements conformes aux préconisations H323, H225 et H235 pour des messages de demande d'admission ARQ (Admission ReQuest), des messages de confirmation d'admission ACF (Admission ConFirm) et des messages de refus d'admission ARJ (Admission ReJect) ainsi que des messages d'établissement d'appel nommés Setup. II existe des architectures réseau dans lesquelles on peut observer un comportement C22 selon lequel, avant d'émettre ou de recevoir un appel, un point d'extrémité est requis d'envoyer un message ARQ vers l'élément de contrôle auprès duquel il est enregistré. Validant une transition 110, une ou plusieurs valeurs de paramètres EPIDr, Dlr, Slr, ou SCSAr reçues avec le message ARQ permettent à l'élément de contrôle d'identifier dans une étape 111 le point d'extrémité. Le champ SI (Src Info) utilisé pour les messages ARQ ou SA (Source Address) utilisé pour les messages Setup, est destiné à contenir un ou plusieurs alias identifiant un point d'extrémité appelant alors que le champ Dl (Destination Info) est destiné à contenir un ou plusieurs alias identifiant un point d'extrémité appelé.
Lorsque l'élément de contrôle envoie en étape 113 un message ACF de confirmation de l'acceptation d'admission, la réception du message ACF par le point d'extrémité appelant valide une transition 112 qui active une étape 115 dans laquelle le point d'extrémité adopte un comportement C23, en respectant une valeur de paramètre cMod (callModel) spécifié dans le message ACF. Le paramètre "callModel" positionné à une valeur "direct", valide une transition 116 qui active une étape 117 dans laquelle le point d'extrémité envoie le message SetUp directement au point d'extrémité appelé. Le paramètre "callModel" positionné à une valeur "GKR" (gatekeeperRouted), valide une transition 118 qui active une étape 119 dans laquelle le point d'extrémité envoie le message SetUp à l'élément de contrôle et c'est l'élément de contrôle qui fait ensuite le relais vers le point d'extrémité appelé. Un comportement C24 rend le paramètre EPID optionnel dans le cas où le message SetUp est envoyé directement au point d'extrémité appelé en étape 117 et impose le paramètre EPID dans le cas où le message SetUp est envoyé à l'élément de contrôle en étape 119. Les paramètres SI et SCSA du message Setup sont optionnels individuellement dans la syntaxe H.225. Le paramètre SCSA (srcCallSignalAddress) utilisé pour les messages ARQ ou (sourceCallSignalAddress) utilisé pour les messages Setup indique une adresse de transport pour le canal de signalisation CS attribuée au point d'extrémité appelant. Un comportement C25 impose d'inclure au moins l'un de ces paramètres dans le message Setup envoyé en étape 117 ou 119.
Les paramètres Dl et DCSA du message Setup sont optionnels individuellement dans la syntaxe H.225. Le paramètre DCSA (dstCallSignalAddress) indique une adresse de transport pour le canal de signalisation CS attribuée au point d'extrémité appelé. Un comportement C26 impose d'inclure au moins l'un de ces paramètres dans le message Setup envoyé en étape 117 ou 119. Dans le cas où les paramètres Dl et DCSA seraient simultanément présents dans le message Setup, le paramètre Dl doit être préféré au paramètre DCSA pour le traitement du message. Si le message SetUp reçu par un point d'extrémité appelé contient le paramètre SCSA, un comportement C27 impose à la valeur de ce paramètre d'être transmise par le point d'extrémité appelé dans le message ARQ qu'il envoie vers l'élément de contrôle.
Le mode de routage du message Setup (gatekeeper routed) appartient à un comportement C28 dans lequel l'élément de contrôle peut modifier l'information de destination DCSA qu'il reçoit avant d'émettre le message SetUp correspondant vers l'entité appelée dans une étape 93 activée par une transition 114 validée par la réception du message Setup en provenance du point d'extrémité appelant.
En référence à la figure 16, une transition 120 est validée lorsqu'un attaquant décide de mener une attaque A11 visant à émettre un appel en usurpant l'identité H.323 d'une entité tierce d'une première manière. Une phase préliminaire à l'attaque A11 consiste à acquérir les valeurs des paramètres d'identification EPID et ALIAS d'un point d'extrémité enregistré auprès de l'élément de contrôle. Cette acquisition d'informations peut être réalisée par une des attaques A1 à A6, ou par tout autre procédé conduisant au même résultat. Dans une étape 121 activée par la transition 120, l'attaquant envoie vers l'élément de contrôle un message ARQ dont les champs EPID et SI sont positionnés aux valeurs EPIDe et ALIASe précédemment déterminées. D'après le comportement C22, et sur la base des valeurs de paramètres EPIDt et SIt, l'élément de contrôle identifie le point d'extrémité appelant comme valide et retourne un message ACF. Suivant le comportement de l'élément de contrôle, le message ACF est retourné vers l'attaquant qui valide une transition 122, ou au contraire vers le point d'extrémité régulier. De façon à favoriser une validation de la transition 122, la valeur de paramètre SCSAt du message ARQ pourra être forcé à l'adresse de transport CSA de l'attaquant, ou si ce n'est pas accepté par l'élément de contrôle, à l'adresse de transport CSA du point d'extrémité régulier. Ensuite l'attaquant poursuit l'appel dans une étape 123 en envoyant un message SetUp vers l'élément de contrôle ou le point d'extrémité appelé, suivant les informations de modèle d'appel (cMOD) retournées dans le message ACF qui valide la transition 122. Les paramètres EPID et SI du message SetUp conserveront les informations de l'entité usurpée. Une absence de réception de message ACF signifie que le message ACF a été envoyé vers le point d'extrémité régulier, l'attaquant envoie alors le message Setup tel qu'indiqué précédemment en fonction des informations de modèle d'appel connues de l'attaquant. Le résultat de l'attaque est la possibilité pour l'attaquant d'établir un appel en se faisant passer pour une entité tierce. En référence à la figure 17, une transition 124 est validée lorsqu'un attaquant décide de mener une attaque A12 visant à émettre un appel en usurpant l'identité H.323 d'une entité tierce d'une deuxième manière. Une phase préliminaire à l'attaque A12 consiste à acquérir les valeurs des paramètres d'identification ALIAS et éventuellement EPID d'un point d'extrémité enregistré auprès de l'élément de contrôle. Dans une étape 125 activée par la transition 124, l'attaquant envoie directement un message Setup vers le point d'extrémité qu'il souhaite appeler en positionnant le champ SI du message Setup à la valeur ALIASe de l'entité dont il souhaite usurper l'identité. On notera que d'après C24, le champ EPID du message Setup est optionnel. Suivant C22, le point d'extrémité appelé enverra ou pas un message ARQ vers l'élément de contrôle avant d'accepter l'appel. Dans le premier cas, l'information SI contenue dans le message Setup est extraite par le point d'extrémité appelé et insérée dans le message ARQ qu'il envoie vers l'élément de contrôle. Le message ARQ envoyé par le point d'extrémité appelé est logiquement accepté par l'élément de contrôle et après réception du message ACF, l'établissement d'appel se poursuit normalement. On notera aussi que le paramètre SCSA du message SetUp pourra être omis ou positionné à l'adresse de transport CSA de l'attaquant, pour forcer le point d'extrémité appelé à lui répondre sur cette adresse. Le résultat de l'attaque A12 est la possibilité pour l'attaquant d'établir un appel en se faisant passer pour une entité tierce. Ce résultat est en tout point similaire à celui de l'attaque A11 , seul le mode opératoire est différent.
En référence à la figure 18, une transition 126 est validée lorsqu'un attaquant décide de mener une attaque A13 visant à émettre un appel en usurpant l'identité H.323 d'une entité tierce d'une troisième manière. Une phase préliminaire à l'attaque A13 consiste à acquérir les valeurs des paramètres d'identification ALIAS d'un point d'extrémité enregistré auprès de l'élément de contrôle. Dans une étape 127 activée par la transition 126, l'attaquant envoie vers l'élément de contrôle un message ARQ contenant ses propres paramètres EPID et SI, suivi en étape 79 d'un message Setup vers l'élément de contrôle dans lequel le paramètre SI est changé en la valeur ALIASe de l'entité tierce. L'étape 79 est par exemple activée par une transition 128 validée par la réception d'un message ACF en provenance de l'élément de contrôle. On notera que dans le cas où le passage d'appel se fait en mode direct, le message Setup est envoyé directement à l'entité appelée, ce qui rejoint l'attaque A12. Le résultat de l'attaque A13 est en tout point similaire à celui des attaques A11 et A12, seul le mode opératoire est différent. Il est à noter ici que l'attaquant a besoin d'être enregistré auprès de l'élément de contrôle pour disposer de paramètres d'enregistrement EPID et SI. Selon les systèmes, l'attaquant peut envoyer dans le message Setup, sa propre valeur de paramètre EPID ou être contraint d'envoyer la valeur de paramètre EPID du point d'extrémité régulier. On indique que les expériences menées sur plusieurs systèmes ont montré des systèmes résistant à certaines des attaques ici présentées mais que ces expériences ont permis de détecter au moins un système vulnérable à chacune de ces attaques tout en étant conforme aux recommandations dans le domaine. Bien que ces attaques sont illustrées dans un environnement qui, en l'absence de témoin TOKEN, ne met pas en œuvre H.235, on comprendra qu'elles sont transposables en mettant H.235 en œuvre dès lors que les messages H.225 comprennent des paramètres de signalisation qui ne sont pas cohérents avec le témoin. L'identification et l'étude des attaques décrites précédemment ont conduit aux définitions et règles de filtrage à présent expliquées en référence aux figures 19 à 24.
La figure 19 montre une série d'étapes 141 à 145 activées lorsqu'un élément de contrôle GK est destinataire d'un message RRQ de type requête d'enregistrement qui valide une transition 140 et une étape 146 lorsqu'un point d'extrémité est destinataire d'un message RCF de type confirmation d'enregistrement qui valide une transition 187.
Suite à validation de la transition 140, une étape d'inspection 141 teste si le champ RA du message RRQ, destiné à indiquer une adresse de transport vers laquelle émettre une réponse au dit message, contient une valeur différente de l'adresse source du message. Une réponse positive au test détecte une condition de filtrage F1.
Une étape d'observation 142 teste si un ensemble de valeurs reçues
ALIASr, CSAr, RAr correspond à un ensemble de paramètres transmis Pri cohérent avec l'état courant de l'élément de contrôle. Le test utilise une fonction de cohérence D1 exécutée à partir d'une étape 147 avec les valeurs de paramètres reçus. Une réponse négative au test détecte une condition de filtrage F2.
En référence à la figure 20, des étapes 148 et 149 sont activées à partir de l'étape 147. L'étape 148 teste si pour chaque paramètre Pri il n'existe dans l'élément de contrôle aucun point d'extrémité PE déjà enregistré ayant un paramètre Pei de même type et de même valeur que Pri.
L'étape 149 teste si pour l'ensemble des paramètres Pn- il existe dans l'élément de contrôle un point d'extrémité PE unique déjà enregistré ayant un ensemble d'autant de paramètres Pei de mêmes types et de mêmes valeurs que l'ensemble des paramètres Pn.
La fonction D1 retourne une réponse de test positif en cas de réponse positive à l'un des deux tests des étapes 148 et 149. En référence à la figure 19, lorsqu'une valeur EPIDr est transmise, une étape d'observation 143 teste si un ensemble de valeurs reçues ALIASr, CSAr, RAr, EPIDr correspond à un ensemble de paramètres transmis Pn cohérent avec l'état courant de l'élément de contrôle. Le test utilise la fonction de cohérence D1 exécutée à partir de l'étape 147 avec les valeurs de paramètres reçus. Une réponse négative au test détecte une condition de filtrage F3.
Une étape d'autorisation 144 teste si une association ALIAS/TOKEN est autorisée en faisant appel à une fonction de cohérence D2 détaillée en référence à la figure 21. Un retour de réponse négative de la fonction D2, détecte une condition de filtrage F4. En référence à la figure 21 , la fonction D2 reçoit en étape 150, une désignation d'association paramètre/témoin dont la cohérence est à vérifier. Par exemple lorsque la fonction D2 est appelée à partir de l'étape 144, la désignation correspond à une valeur de paramètre Pn égale à la valeur ALIASn et à une valeur de témoin égale à la valeur TOKENn si elle est transmise dans le message H225 reçu. Deux conditions sont nécessaires à la vérification de l'autorisation.
Une transition 190 est validée lorsque la valeur du témoin TOKEN est transmise dans le message reçu et une transition 191 est validée lorsque la valeur du témoin TOKEN n'est pas transmise dans le message reçu. Le témoin au sens de la recommandation H.235, est par exemple une clé secrète prévue pour accréditer une valeur de paramètre associé. La transition 190 active une étape 151 qui teste si le point d'extrémité que le témoin identifie possède un attribut Pei de même type et de même valeur que Pri. La première condition est vérifiée en cas de réponse positive au test de l'étape 151 ou en cas de validation de la transition 191. Une transition 192 est validée lorsque le paramètre associé n'est pas de type identifiant ALIAS de point d'extrémité et une transition 193 est validée lorsque le paramètre associé est de type identifiant ALIAS de point d'extrémité.
La transition 193 active une étape 152 qui teste si la valeur du paramètre Pri fait partie de la plage d'ALIAS provisionnée par l'opérateur. Un ALIAS est provisionné lorsqu'il est réservé par l'opérateur à un point d'extrémité donné, que ce point d'extrémité soit déjà enregistré ou pas auprès de l'élément de contrôle. La deuxième condition est vérifiée en cas de réponse positive au test de l'étape 152 ou en cas de validation de la transition 192.
La fonction D2 retourne une réponse de test négatif en cas de réponse négative à l'un des deux tests des étapes 151 et 152.
Aussi bien pour la fonction de cohérence D1 que pour la fonction de cohérence D2, si un paramètre Pri est de type adresse source (AS), ce paramètre est assimilé à un paramètre de type rasAdress (RA) de valeur égale à celle de l'adresse source désignée par Pri. En référence à la figure 19, une étape d'évaluation teste si le message
RRQ contient un paramètre de type durée de validité d'enregistrement de valeur TTLr reçue inférieure à un seuil prédéfini par l'opérateur de valeur ε. La valeur ε sera typiquement inférieure à la durée d'enregistrement appliquée par défaut dans le réseau, et de l'ordre de quelques secondes. On indique que la valeur du seuil peut varier selon l'architecture et les équipements déployés par l'opérateur du réseau. Néanmoins, il est recommandé de ne pas dépasser pour ε une valeur de 60 secondes. Une réponse positive au test détecte une condition de filtrage F5.
Suite à validation de la transition 187, une étape de surveillance 146 teste si le message RCF reçu par le point d'extrémité régulier en provenance de l'élément de contrôle (gatekeeper) auprès duquel il est enregistré, ne fait suite à aucun message de requête RRQ préalablement émis par ce point d'extrémité. Une réponse positive au test détecte une condition de filtrage F6.
En référence à la figure 22, un message URQ reçu par un élément de contrôle (gatekeeper) valide une transition 153 qui active des étapes 154 à 156. L'étape 154 teste si un ensemble de valeurs reçues ASr, CSAr, EPIDr correspond à un ensemble de paramètres transmis Pri cohérent avec l'état courant de l'élément de contrôle en faisant appel à la fonction de cohérence D1 exécutée à partir de l'étape 147 avec les valeurs de paramètres reçus. Une réponse négative au test détecte une condition de filtrage F7. L'étape 155 teste si le message URQ contient bien un paramètre ALIAS et si un ensemble de valeurs reçues ALIASr, CSAr, correspond à un ensemble de paramètres transmis Pri cohérent avec l'état courant de l'élément de contrôle en faisant appel à la fonction de cohérence D1 exécutée à partir de l'étape 147 avec les valeurs de paramètres reçus. Une réponse négative au test détecte une condition de filtrage F9.
L'étape 156 teste si une association CSA/TOKEN est autorisée en faisant appel à la fonction D2 détaillée en référence à la figure 21. Un retour de réponse négative de la fonction D2, détecte une condition de filtrage F11.
Un message URQ reçu par un point d'extrémité valide une transition 159 qui active une étape 160 teste si l'adresse source AS est différente de l'adresse de transport utilisée pour le canal RAS de l'élément de contrôle auprès duquel le point d'extrémité est enregistré, ou si le paramètre CSA n'est pas cohérent car différent de l'adresse de transport pour le canal CS du point d'extrémité. Une réponse positive au test détecte une condition de filtrage F8. Un message UCF reçu par l'élément de contrôle ou le point d'extrémité, valide respectivement une transition 157 ou 161 qui active respectivement une étape de surveillance 158 ou 162 qui teste si ce message ne correspond à aucun message de requête URQ émis préalablement en direction de l'élément de réseau d'où provient le message UCF. Une réponse positive au test détecte une condition de filtrage F10. En référence à la figure 23, des étapes d'inspection 169, 173 testent si le champ RPA d'un message LRQ ou IRQ, destiné à indiquer une adresse de transport vers laquelle émettre une réponse au dit message, contient une valeur différente de l'adresse source du message. Une réponse positive au test détecte une condition de filtrage F12. Un message LRQ à destination de l'élément de contrôle valide une transition 163. Un message IRQ à destination du point d'extrémité valide une transition 170. L'étape 169 est activée par validation de la transition 163. L'étape 173 est activée par validation de la transitions 170.
La transition 163 active une étape d'observation 164 qui teste la cohérence du paramètre Dl du message LRQ en tant qu'identifiant enregistré avec une valeur ALIASe auprès de l'élément de contrôle ayant reçu le message LRQ. Une réponse négative au test détecte une condition de filtrage F13.
La transition 163 active une étape d'observation 165 faisant appel à la fonction D1 en lui soumettant l'ensemble de paramètres {Dl, EPID}. Une réponse négative au test détecte une condition de filtrage F14.
La transition 170 active une étape d'observation 171 dans laquelle, un état courant du point d'extrémité comprend l'adresse de transport RA(GK) de l'élément de contrôle auprès duquel le point d'extrémité est enregistré. L'adresse source du message IRQ est un paramètre cohérent si sa valeur est égale à l'adresse RA(GK). L'étape 171 a pour fonction de détecter une incohérence qui constitue alors une condition de filtrage F15.
La transition 170 active une étape d'observation 167 qui, lorsque le message IRQ transmet un paramètre CRV non nul, teste si un ensemble de valeurs reçues CRVr, CIDr correspond à un ensemble de paramètres transmis Pri cohérent avec l'état courant du point d'extrémité. Les valeurs reçues sont cohérentes si elles correspondent à un appel en cours. Une réponse négative au test détecte une condition de filtrage F16.
La transition 163 et la transition 170, activent respectivement l'étape d'autorisation 168 et l'étape d'autorisation 174 qui testent si l'association AS/TOKEN est autorisée en faisant appel à la fonction D2. Pour le test, l'adresse source AS est assimilée à une adresse RA de même valeur. Une réponse négative à un test détecte une condition de filtrage F17.
En référence à la figure 24, un message ARQ et un message Setup à destination de l'élément de contrôle, valident respectivement une transition 175 et une transition 181. Une succession de messages ARQ, Setup à destination de l'élément de contrôle, valide une transition 188. Un message à destination d'un point d'extrémité, valide une transition 185.
Lorsque le message ARQ contient un champ SI, la transition 175 active une étape d'observation 176 qui teste si un ensemble de valeurs reçues ASr, Slr, EPIDr correspond à un ensemble de paramètres transmis Pri cohérent avec l'état courant de l'élément de contrôle en faisant appel à la fonction de cohérence D1 exécutée à partir de l'étape 147 avec les valeurs de paramètres reçus. Une réponse négative au test détecte une condition de filtrage F18.
Lorsque le message Setup contient un champ SI, la transition 181 active une étape d'observation 182 qui teste si un ensemble de valeurs reçues ASr, Slr, EPIDr correspond à un ensemble de paramètres transmis Pri cohérent avec l'état courant de l'élément de contrôle en faisant appel à la fonction de cohérence D1 exécutée à partir de l'étape 147 avec les valeurs de paramètres reçus. Une réponse négative au test détecte une condition de filtrage F21. Lorsque le message ARQ contient un champ SCSA, la transition 175 active une étape d'observation 177 qui teste si un ensemble de valeurs reçues SCSAr, ASr, EPIDr correspond à un ensemble de paramètres transmis Pri cohérent avec l'état courant de l'élément de contrôle en faisant appel à la fonction de cohérence D1 exécutée à partir de l'étape 147 avec les valeurs de paramètres reçus. Une réponse négative au test détecte une condition de filtrage F19.
Lorsque le message Setup contient un champ SCSA, la transition 181 active une étape d'observation 183 qui teste si un ensemble de valeurs reçues SCSAr, ASr, EPIDr correspond à un ensemble de paramètres transmis Pri cohérent avec l'état courant de l'élément de contrôle en faisant appel à la fonction de cohérence D1 exécutée à partir de l'étape 147 avec les valeurs de paramètres reçus. Une réponse négative au test détecte une condition de filtrage F22. La transition 175 active une étape 178 qui teste si une association EPID/TOKEN est autorisée en faisant appel à la fonction de cohérence D2 détaillée en référence à la figure 21. Un retour de réponse négative de la fonction D2, détecte une condition de filtrage F20. La transition 181 active une étape 184 qui teste si une association
EPID/TOKEN est autorisée en faisant appel à la fonction de cohérence D2 détaillée en référence à la figure 21. Un retour de réponse négative de la fonction D2, détecte une condition de filtrage F23.
La transition 175 active une étape 179 qui mémorise les valeurs de champs Slra, SCSAra reçues avec le message ARQ. A la suite de l'étape 179, une réception par l'élément de contrôle, de message sur le canal de signalisation CS provenant du même point d'extrémité que le message ARQ, valide une transition
188.
La transition 188 active une étape d'observation 180 dans laquelle un état courant de l'élément de contrôle comprend les valeurs mémorisées en étape 179.
L'étape 180 teste si les valeurs SU, SCSAr8 reçues avec le deuxième message
(Setup) sont égales à celles du premier message (ARQ). Une réponse négative au test détecte une condition de filtrage F24.
La transition 185 active une étape d'observation 186 dans laquelle un état courant du point d'extrémité comprend les valeurs d'identifiant DI(PE) et d'adresse de transport DCSA(PE) connues du point d'extrémité. L'étape 185 teste si les valeurs Dlr, DCSAr reçues avec le message Setup sont respectivement égales à celles connues. Une réponse négative au test détecte une condition de filtrage F25. Les étapes du procédé décrit en référence aux figures 19 à 24 permettent de sécuriser le réseau face à de nombreuses attaques.
Par exemple lors d'une attaque A1 , l'étape 41 est filtrable par l'étape 142, voire 143 car l'adresse CSA de l'attaquant ne correspond pas à l'adresse CSA de l'attaqué. Lors d'une attaque A2, l'étape 47 est filtrable par l'étape 142 car l'adresse RA ne correspond pas à l'adresse RA de l'attaqué. Lors d'une attaque
A3, l'étape 53 est filtrable par l'étape 142 car l'identifiant de point d'extrémité n'est pas cohérent avec l'adresse de transport pour canal de signalisation d'appel. Lors d'une attaque A6, l'étape 67 est filtrable par l'étape 142 si l'adresse RA est celle de l'attaquant ou si ce n'est pas le cas, le point d'extrémité peut remédier à l'attaque grâce à l'étape 146.

Claims

Revendications
1. Procédé de sécurisation d'un réseau de communication audiovisuelle dans lequel un premier point d'extrémité (1 ,2,3,5) échange des messages avec un élément de contrôle (4), les messages transmettant des paramètres enregistrés ou à enregistrer dans l'élément de contrôle pour permettre au premier point d'extrémité (1 ,2,3,5) de communiquer avec au moins un deuxième point d'extrémité (1 ,2,3,5) enregistré dans l'élément de contrôle (4), caractérisé en ce qu'il comprend une étape d'observation consistant à détecter si un ensemble de paramètres parmi les paramètres transmis dans un message, n'est pas cohérent avec un état courant du destinataire (1 ,2,3,4) du dit message.
2. Procédé de sécurisation selon la revendication 1 , caractérisé en ce que, le destinataire du message étant l'élément de contrôle (4),
- l'ensemble de paramètres transmis est cohérent (148) si chaque paramètre de l'ensemble ne correspond à aucun paramètre de type et de valeur identiques de point d'extrémité enregistré dans l'élément de contrôle, ou
- l'ensemble de paramètres transmis est cohérent (149) s'il existe un ensemble comportant un même nombre de paramètres de types et de valeurs respectivement identiques pour un unique point d'extrémité déjà enregistré dans l'élément de contrôle.
3. Procédé de sécurisation selon l'une des revendications précédentes, caractérisé en ce qu'il comprend une étape d'autorisation (144,156,168,174,178,184) consistant à détecter pour un paramètre transmis associable à un témoin:
- lorsqu'il existe un témoin transmis, si (151 ) le paramètre transmis n'est pas de type et de valeur identiques au type et à la valeur d'un attribut de point d'extrémité accrédité par le témoin; et
- lorsque le paramètre transmis est de type identifiant de point d'extrémité, si (152) la valeur du dit paramètre n'appartient pas à une plage de valeurs d'identifiants provisionnée pour le point d'extrémité.
4. Procédé de sécurisation selon l'une des revendications 2 ou 3, caractérisé en ce que, lorsqu'un paramètre de l'ensemble de paramètres transmis, est de type adresse source, ledit paramètre est assimilé à un paramètre de type adresse de transport pour canal RAS de même valeur.
5. Procédé de sécurisation selon l'une des revendications précédentes, caractérisé en ce que, lorsque (140) le message est de type requête d'enregistrement auprès de l'élément de contrôle, l'ensemble de paramètres devant être cohérent comprend (142) un paramètre de type identifiant, un paramètre de type adresse de transport pour canal de signalisation et un paramètre de type adresse de transport pour canal RAS.
6. Procédé de sécurisation selon la revendication 5, caractérisé en ce que l'ensemble devant être cohérent comprend (143) de plus une clé d'identité d'enregistrement de point d'extrémité lorsque ladite clé est présente dans ledit message.
7. Procédé de sécurisation selon l'une des revendications précédentes, caractérisé en ce qu'il comprend une étape d'évaluation (145) consistant à détecter lorsque le message contient un paramètre de type durée de validité d'enregistrement, si ledit paramètre a une valeur inférieure à un seuil prédéfini par un opérateur du réseau.
8. Procédé de sécurisation selon la revendication 1 , caractérisé en ce qu'il comprend une étape de surveillance (146,162) consistant à détecter si un message de type confirmation d'enregistrement ou de désenregistrement reçu par le destinataire n'est pas précédé respectivement par un message de type requête d'enregistrement ou de désenregistrement émis par ledit destinataire.
9. Procédé de sécurisation selon les revendications 2 et 4, caractérisé en ce que, lorsque le message est de type requête de désenregistrement auprès de l'élément de contrôle, l'ensemble de paramètres devant être cohérent (154) comprend un paramètre de type adresse de transport pour canal de signalisation, une adresse source et une clé d'identité d'enregistrement de point d'extrémité.
10. Procédé de sécurisation selon la revendications 2, caractérisé en ce que, lorsque le message est de type requête de désenregistrement auprès de l'élément de contrôle, l'ensemble de paramètres devant être cohérent (155) comprend un paramètre de type adresse de transport pour canal de signalisation et un paramètre de type identifiant de point d'extrémité lorsque ledit identifiant est présent dans ledit message.
11. Procédé de sécurisation selon la revendication 3, caractérisé en ce que, lorsque le message est de type requête de désenregistrement auprès de l'élément de contrôle, le paramètre transmis associable à un témoin (156) est un paramètre de type adresse de transport pour canal de signalisation.
12. Procédé de sécurisation selon la revendications 1 , caractérisé en ce que, lorsque le message est de type requête de localisation, l'ensemble de paramètres transmis comprend (164) un paramètre de type identifiant de destination qui, pour être cohérent doit avoir une valeur égale à celle d'un identifiant de point d'extrémité enregistré.
13. Procédé de sécurisation selon la revendication 12, caractérisé en ce que l'ensemble devant être cohérent comprend de plus (165) un paramètre de type clé d'identité d'enregistrement de point d'extrémité lorsque ladite clé est présente dans ledit message.
14. Procédé de sécurisation selon la revendication 1 , caractérisé en ce que, lorsque le message est de type requête d'information, l'ensemble de paramètres devant être cohérent comprend (167) un paramètre de type référence d'appel non nul et un paramètre de type identificateur d'appel.
15. Procédé de sécurisation selon la revendication 1 , caractérisé en ce que, lorsque le destinataire est un point d'extrémité et que le message est de type requête d'information, l'ensemble de paramètres devant être cohérent comprend (171 ) une adresse source de l'émetteur qui doit être égale à l'adresse source de l'élément de contrôle auprès duquel le point d'extrémité est enregistré.
16. Procédé de sécurisation selon les revendications 3 et 4, caractérisé en ce que, lorsque le message est de type requête de localisation ou de type requête d'information, le paramètre transmis en association (168,174) avec le paramètre témoin est un paramètre de type adresse source.
17. Procédé de sécurisation selon l'une des revendications 1 à 4, caractérisé en ce que, lorsque le message est de type requête d'admission, l'ensemble de paramètres devant être cohérent comprend (176) un paramètre de type adresse source, un paramètre de type identifiant de point d'extrémité appelant et une clé d'identité d'enregistrement de point d'extrémité.
18. Procédé de sécurisation selon l'une des revendications 1 à 4, caractérisé en ce que, lorsque le message est de type requête d'admission, l'ensemble devant être cohérent comprend (177) un paramètre de type adresse source, un paramètre de type adresse de transport pour canal de signalisation d'appel utilisée par le point d'extrémité appelant et une clé d'identité d'enregistrement de point d'extrémité.
19. Procédé de sécurisation selon la revendication 3, caractérisé en ce que, lorsque le message est de type requête d'admission ou de type établissement d'appel, le paramètre transmis associable (178,184) avec le paramètre témoin est un paramètre de type clé d'identité d'enregistrement de point d'extrémité.
20. Procédé de sécurisation selon l'une des revendications 1 à 4, caractérisé en ce que, lorsque le message est de type établissement d'appel, l'ensemble de paramètres devant être cohérent comprend (182) un paramètre de type adresse source, un paramètre de type identifiant de point d'extrémité appelant et une clé d'identité d'enregistrement de point d'extrémité lorsque l'identifiant de point d'extrémité appelant est présent dans ledit message.
21. Procédé de sécurisation selon l'une des revendications 1 à 4, caractérisé en ce que, lorsque le message est de type établissement d'appel, l'ensemble de paramètres devant être cohérent comprend (183) un paramètre de type adresse source, un paramètre de type adresse de transport pour canal de signalisation utilisée par le point d'extrémité appelant et une clé d'identité d'enregistrement de point d'extrémité lorsque ladite adresse de transport pour canal de signalisation est présente dans ledit message.
22. Procédé de sécurisation selon les revendications 1 et 4, caractérisé en ce que, lorsque le message est de type requête d'enregistrement, le paramètre transmis en association (144) avec le paramètre témoin est un paramètre de type identifiant de point d'extrémité.
23. Procédé de sécurisation selon l'une des revendications 1 à 4, caractérisé en ce que, lorsque (179) le message est de type établissement d'appel précédé par un message de type requête d'admission, il comprend une étape de vérification consistant à détecter si le message de type établissement d'appel comprend (180) un paramètre de type identifiant ou adresse de transport pour canal de signalisation de point d'extrémité appelant avec une valeur différente de celle transmise par le message de type requête d'admission.
24. Procédé de sécurisation selon la revendication 1 , caractérisé en ce que, lorsque le destinataire est un point d'extrémité et que le message est de type établissement d'appel, l'ensemble de paramètres devant être cohérent comprend (186) un paramètre de type identifiant ou adresse de transport désignant le point d'extrémité appelé.
25. Procédé de sécurisation selon la revendication 1 , caractérisé en ce que, lorsque le destinataire est un point d'extrémité et que le message est de type requête de désenregistrement, l'ensemble de paramètres devant être cohérent (160) comprend un paramètre de type adresse de transport pour canal de signalisation d'appel et une adresse source auquel correspond un état du destinataire comprenant l'adresse de transport pour canal de signalisation d'appel utilisée par le destinataire et l'adresse de transport pour canal RAS utilisée par l'élément de contrôle auprès duquel le destinataire est enregistré.
26. Procédé de sécurisation selon l'une des revendications précédentes, caractérisé en ce qu'il comprend une étape d'inspection (141 ,169,173) consistant à détecter si une adresse source du message est de valeur différente d'une valeur de paramètre contenu dans le message pour indiquer une adresse de transport vers laquelle émettre une réponse au dit message.
EP06726190A 2005-02-25 2006-02-21 Procede de securisation d'un reseau de communication audiovisuelle Withdrawn EP1851933A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0502110 2005-02-25
PCT/FR2006/050152 WO2006090083A1 (fr) 2005-02-25 2006-02-21 Procede de securisation d'un reseau de communication audiovisuelle

Publications (1)

Publication Number Publication Date
EP1851933A1 true EP1851933A1 (fr) 2007-11-07

Family

ID=35198007

Family Applications (1)

Application Number Title Priority Date Filing Date
EP06726190A Withdrawn EP1851933A1 (fr) 2005-02-25 2006-02-21 Procede de securisation d'un reseau de communication audiovisuelle

Country Status (3)

Country Link
US (1) US8090846B2 (fr)
EP (1) EP1851933A1 (fr)
WO (1) WO2006090083A1 (fr)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9106405B1 (en) 2012-06-25 2015-08-11 Amazon Technologies, Inc. Multi-user secret decay
US9038148B1 (en) * 2012-08-23 2015-05-19 Amazon Technologies, Inc. Secret variation for network sessions
US9203818B1 (en) 2012-08-23 2015-12-01 Amazon Technologies, Inc. Adaptive timeouts for security credentials

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH09102831A (ja) * 1995-07-31 1997-04-15 Canon Inc 通信システム及び通信装置及び通信方法
US7167897B2 (en) * 1996-05-08 2007-01-23 Apple Computer, Inc. Accessories providing a telephone conference application one or more capabilities independent of the teleconference application
CA2297341A1 (fr) * 1999-08-18 2001-02-18 Alma-Baba Technical Research Laboratory Co., Ltd. Systeme de surveillance de reseau destine a empecher les attaques des pirates informatiques
US6859448B1 (en) 1999-09-16 2005-02-22 At&T Corp. H.323 mobility protocol for terminal, user and service mobility
US6704769B1 (en) * 2000-04-24 2004-03-09 Polycom, Inc. Media role management in a video conferencing network
US20020188725A1 (en) * 2001-05-31 2002-12-12 Mani Babu V. User verification service in a multimedia-capable network
US7437762B2 (en) * 2001-11-29 2008-10-14 International Business Machines Corporation Method, computer program element and a system for processing alarms triggered by a monitoring system
US20050213726A1 (en) * 2001-12-31 2005-09-29 Polycom, Inc. Conference bridge which transfers control information embedded in audio information between endpoints
US7441429B1 (en) * 2006-09-28 2008-10-28 Narus, Inc. SIP-based VoIP traffic behavior profiling

Non-Patent Citations (1)

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

Also Published As

Publication number Publication date
US8090846B2 (en) 2012-01-03
WO2006090083A1 (fr) 2006-08-31
US20080201482A1 (en) 2008-08-21

Similar Documents

Publication Publication Date Title
EP4066461B1 (fr) Procédé de coordination de la mitigation d'une attaque informatique, dispositif et système associés
US20130287029A1 (en) Preventing illicit communications
EP1931105A1 (fr) Procédé et système de gestion de sessions multimédia, permettant de contrôler l'établissement de canaux de communication
WO2005060138A2 (fr) Systemes et procedes d'interdiction de messages spam et de prevention d'attaques entrainant un refus de service dans des reseaux de messagerie, multimedia a paquets et autres
KR20100017303A (ko) 통합 전화 네트워크에서의 원치않는 전화 광고의 검출 방법 및 제거 방법
CA2326246C (fr) Methodes et systemes de surveillance du protocole internet (ip) dans un reseau
WO2018109377A1 (fr) Procédé et dispositif de surveillance mis en œuvre par un point d'accès à un réseau de télécommunications
US20090138959A1 (en) DEVICE, SYSTEM AND METHOD FOR DROPPING ATTACK MULTIMEDIA PACKET IN THE VoIP SERVICE
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
EP1894350B1 (fr) Securisation de la telephonie sur ip
FR2934451A1 (fr) Etablissement et controle d'appel par equipement tiers.
EP1869858A2 (fr) Procede de lutte contre l'envoi d'information vocale non sollicitee
EP2080345A2 (fr) Procede et gestion d'identites publiques dans un reseau de transmission d'informations, serveur de gestion d'enregistrements d'identites publiques, equipement de gestion d'une identite publique de groupe et programmes d'ordinateur correspondants
EP1851933A1 (fr) Procede de securisation d'un reseau de communication audiovisuelle
FR3058015A1 (fr) Procede de controle dynamique et interactif d'une passerelle residentielle connectee a un reseau de communication, dispositif et programme d'ordinateur correspondants
FR2892585A1 (fr) Procede et systeme de protection d'un lien d'acces a un serveur.
EP3560168B1 (fr) Classification et aiguillage de messages de contrôle d'une infrastructure de communications
EP1964363B1 (fr) Procédé de transfert de flux de communication
EP1964368B1 (fr) Procede et passerelle de raccordement d'entites de communication ip par l'intermediaire d'une passerellle residentielle
EP3857849B1 (fr) Procédés de protection d'un domaine client, noeud client, serveur et programmes d'ordinateur correspondants
Nassar et al. VoIP malware: Attack tool & attack scenarios
FR2842681A1 (fr) Procede et systeme d'avertissement et de diffusion d'informations par un reseau public de transmission de donnees numeriques
EP4453765A1 (fr) Procédés d'identification d'au moins un serveur de mitigation et de protection d'un domaine client contre une attaque informatique, dispositifs et signal correspondants
WO2013156727A1 (fr) Procede de traitement d'un message, entite et cœur de reseau
WO2008001015A2 (fr) Procédé d'identification de terminal appelant

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: 20070828

AK Designated contracting states

Kind code of ref document: A1

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: 20111205

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: 20160429