MCData IPCON Session Establishment Procedure

Abstract

One aspect of the invention relates to a method for establishing an IPCON (Mission Critical Data Internet Protocol Connectivity) MCData session in a communication network according to the 3GPP MCS (3rd Generation Partnership Program Mission Critical System) standard. The network comprises a sending MCData entity, a receiving MCData entity, and an MCData transport service connected to the sending and receiving MCData entities.The process includes: Obtaining (20), by the sending MCData entity, a DPPK "MCData Payload Protection Key" and a DPPK-ID "MCData Payload Protection Key Identifier", Transmitting (30), by the sending MCData entity to the receiving MCData entity via the MCData transport service a SIP-INVITE message including the DPPK and the DPPK-ID, Authenticating (40), by the receiving MCData entity, the message, and Determining (50), by the receiving MCData entity, the DPPK and the DPPK-ID and establishing an IP tunnel between the sending MCData entity and the receiving MCData entity.

Description

Description Title of the invention: Method for establishing an MCData session IPCON TECHNICAL FIELD OF THE INVENTION

[0001] The technical field of the invention is that of telecommunications.

[0002] The present invention relates to a method for establishing an MCData session Internet Protocol Connectivity (IPCON) and in particular a method of establishing IPCON session in a communication network according to the 3GPP MCS standard “3rd Generation Partnership Program Mission-Critical System.” TECHNOLOGICAL BACKGROUND OF THE INVENTION

[0003] PMR radiocommunication standards (according to the Anglo-Saxon term " Professional Mobile Radio» for “Professional Mobile Radio”) TETRAPOL®, TETRA® or P25® allow the implementation of professional networks secure. These narrowband networks are national or local networks: they are implemented for example within an organization such as a company, within of a country for example for communications of firefighters, police forces, military personnel etc.

[0004] — These networks are evolving towards supporting broadband exchanges. The 3GPP standard governing “GSM” type mobile networks according to the name Anglo-Saxon "Global System for Mobile Communications", notably in their third, fourth and fifth generations respectively called “3G”, “4G” and “5G”, and subsequent generations, and more particularly in deployments using critical communications services defined by 3GPP called “ MCS" according to the Anglo-Saxon term "Mission Critical Services" allows these secure broadband exchanges. A 3G, 4G or 5G network implements a 3G / 4G / 5G terminal equipment (called UE from the English “User Equipment”), a 3G / 4G / 5G Radio Access Network (RAN) and a core network (3G / 4G / 5G). Deployments of MCS broadband services are not are of course not limited to 3G / 4G / 5G mobile networks but also include de- deployments in fixed and mobile IP (Internet Protocol) networks, by example of WLAN, from the English “Wide Local Area Network”.

[0005] — “Communication network according to the 3GPP MCS standard” means a network communication compatible with the 3GPP MCS standard and more particularly with the current version of 3GPP which is version 17 and with the following versions incorporating all the features of the invention.

[0006] = In the 3GPP MCS standard, the following communication services are defined: MCPTT, from the English “Mission Critical Push To Talk” for “Press To Speaking in Mission Critical” in French, which allows for communication voice communications, MCVideo, which allows video communications, MCData, which includes three sub-services: SDS from the English “Short Data Service” for “Data Service” short » in French and FD from the English “File Distribution” for “File Distribution” in French, IPCON from the English “IP Connectivity” for “IP Connectivity” in French. The MCData SDS service allows the transport of payloads of variable size. The MCData SDS service covers status and messaging functionalities. This can be a text or extended message, a hyperlink allowing users to access related and accessible content such as a large file, situational awareness data, location information or command instructions. The MCData IPCON service concerns the sending of useful data between two MCData clients. It should be noted that, unlike the MCData SDS service, the MCData IPCON service is a transport service agnostic to the nature of application exchanges. Thus, the MCData IPCON service allows the exchange of IP data using the MCData transport service as an intermediary and ensures the transport of IP data for, for example, data hosts, servers, etc. The data exchange is not limited to a transaction. [Fig. 1] is a schematic representation of a system that can be used to implement the MCData IPCON service. The MCData clients 220 allow bidirectional communication of IP data 200 with the support of the IP connectivity service which thus constitutes the gateway to the hosts 210 or data servers 210. The sending MCData client 220 requests from the MCData transport service 230 a quality of service requirement and the associated communication priority. The IP “Internet Protocol” tunnel 240 between the two MCData clients 220 is an IP routing tunnel of data 200, in particular media data. Each of the two MCData clients 220 is connected 250 to the MCData transport service 230. It should be noted that an MCData client, which supports IP connectivity capabilities, is able to prohibit incoming IP connectivity requests, either on demand or by providing a list of excluded origins identified by the MCData identifier and, if possible, by the functional alias. The current specifications, defined in the technical specifications document TS 23.282 of the 3GPP standard for MCData IPCON communications includes the establishment and deletion of an IP 240 tunnel between two MCData 220 clients. No security is currently provided for the IP tunnel between two MCData clients. Thus, at present, the security of the data 200 transported through the IP tunnel 240 relies on the data security applied by the application servers 210. However, data security applied by application servers 210 is sometimes not sufficient or even completely absent. For the moment, no solution has been found concerning MCData IPCON communications in the technical specification documents TS 23.282 of the 3GPP standard dedicated to functional architecture and procedures and TS 24.282 of the 3GPP stage 3 standard dedicated to protocol and implementation. Therefore, there is a need to provide a method that complies with the 3GPP R17 specifications and provides security for MCData IPCON communications. In other words, security for the content to be transported end-to-end between MCData clients implementing the IP tunnel must be provided. In addition, this security must be activatable and deactivatable. The process must also allow for media data management. The IP tunnel, established on the media plane between MCData IP clients, allows for the exchange of media data between external application entities. MCData IP clients must therefore be able to control access to this IP tunnel: this is done on the MCData control plane beforehand and on the media plane by securing the data passing through this IP tunnel. To ensure media data management, the process must be compatible with GRE in UDP tunnels as recommended in the 3GPP standard TS 24.582 technical specification document for media data management in clause 13.4. GRE in UDP encapsulation is described in IETF RFC 8086 "Internet Engineering Task Force Request for Comments: 8086". The GRE-in-UDP encapsulation format contains a UDP header and a GRE header. It should be noted that these header elements must not be altered by the process enabling the security of MCData IPCON communications. Finally, at present, MCData IPCON communications only concern point-to-point communications. Thus, group MCData IPCON communications do not exist. A group can be defined as a virtual group of several user devices that can interact with each other once authorized by the communication network, for example authenticated to a group management server of the communication network, thus allowing access to the communication group. Thus, the invention aims to provide a method for establishing communications MCData IPCON secure end-to-end, for both point-to-point and group communications. Summary of the invention The invention provides a solution to the problems mentioned above, by defining a mechanism for generating, distributing and deriving keys for the MCData IPCON service, as well as a mechanism for encrypting the MCData IPCON content. One aspect of the invention relates to a method for establishing an MCData IPCON “Mission Critical Data IP Connectivity” session in a communication network according to the 3GPP MCS “3rd Generation Partnership Program Mission Critical System” standard, the network comprising: an issuing MCData entity: a recipient MCData entity; and an MCData transport service connected to the MCData issuing entities and RECIPIENT ; the method comprising: obtain, by the issuing MCData entity, a DPPK key “MCData Payload Protection Key” and a DPPK-ID key identifier “MCData Payload Protection Key Identifier”; transmit, by the sending MCData entity to the receiving MCData entity via the MCData transport service a SIP-INVITE message including the key DPPK and the key identifier DPPK-IK; authenticate, by the recipient MCData entity, the message; determine, by the recipient MCData entity, the DPPK key and the identifier of the DPPK-ID key and establish an IP tunnel between the sending MCData entity and the entity MCData recipient. Thanks to the invention, end-to-end security is ensured between two MCData entities in an IPCON communication. Thus, even if the content to be sent is not secured by the application servers when it is received by the sending entity, the invention will make it possible to secure the transmission of the content between the sending entity and the receiving entity. In addition to the characteristics which have just been mentioned in the preceding paragraph, the method according to one aspect of the invention may have one or more additional characteristics among the following, considered individually or according to all technically possible combinations: Method according to the invention in which the transmitting MCData entity is connected to a sending application entity and the receiving MCData entity is connected to at least one recipient application entity, the method further comprising, the final steps: Transmit, by the issuing application entity, useful data to the issuing MCData entity. Generate, by the sending MCData entity, a data packet including: the encrypted payload using the DPPK key and the DPPK-ID key identifier: and a header; Send, by the sending MCData entity, the generated data packet to the receiving MCData entity via the established IP tunnel; Remove, by the receiving MCData entity, the header of the generated data packet and decrypt the encrypted payload data using the DPPK key and the DPPK-ID key identifier: and Transmit, by the recipient MCData entity, the decrypted useful data to at least one recipient application entity. Method according to the invention in which: the IP tunnel is a GRE “Generic Routing Encapsulation” tunnel in the UDP “User Datagram Protocol” protocol; and The header is a GRE and UDP type header. Method according to the invention further comprising the prior steps: get information MCData IPCON session establishment authorization, configured with an MCData media plane, between the sending MCData entity and the receiving MCData entity; and the need to implement the method according to the invention; and Implement the method for establishing an MCData IPCON “Mission Critical Data IP Connectivity” session according to the invention when the establishment of an MCData IPCON session, configured with the MCData media plan, between the sending MCData entity and the receiving MCData entity is authorized and if the implementation of the method according to the invention is necessary. Method according to the invention in which: said method is an MCData session establishment method Group IPCON; the issuing MCData entity is an MCData client belonging to a MCData group; the recipient MCData entity is a set of MCData clients ap- belonging to the same MCData group as the MCData entity transmitter; and the DPPK key is a GMK “Group Master Key” type key and the DPPK-ID key identifier is of type GMK-ID “Group Master Key Identifier ». Process in which: said method is an MCData session establishment method IPCON point to point; the sending MCData entity and the receiving MCData entity are MCData customers; and the DPPK key is a private key of type PCK “Private Call Key” and the DPPK-ID key identifier is of type PCK-ID “Private Call Key Identifier » and the PCK key including the identity encryption of the recipient MCData entity; an initial step of obtaining, by the issuing MCData entity and the recipient MCData entity. encryption elements; obtaining at the stage, by the issuing MCData entity, of the PCK key and of the PCK-ID key identifier consists of a generation of the key PCK and PCK-ID identifier using the elements of encryption obtained at step; the SIP-INVITE message transmitted to the step by the MCData entity issuer to the recipient MCData entity, includes a container MIKEY-SAKKE I-MESSAGE « Multimedia Internet KEYing- Sakai-Kasahara Key Encryption”, the MIKEY-SAKKE 1- container MESSAGE including the DPPK key encrypted with a method of SAKKE encryption; and the key identifier DPPK-ID; and the determination by the recipient MCData entity of the PCK key and the PCK-ID key identifier is made using the elements of encryption obtained at the initial stage. Another aspect of the invention relates to a communication network according to the 3GPP MCS “3rd Generation Partnership Program Mission-Critical System” standard, the communication network comprising: an issuing MCData entity; a recipient MCData entity; an MCData transport service connected to the MCData issuing entities and RECIPIENT ; the communication network being configured to implement the method according to the invention. In addition to the characteristics which have just been mentioned in the preceding paragraph, the communication network according to one aspect of the invention may have the character- following characteristic: network according to the invention in which the recipient MCData entity is: a set of MCData clients belonging to the same group MCData that the issuing MCData entity; or an MCData client. According to a third aspect of the invention, there is provided a computer program product comprising instructions which cause the system according to the invention to execute the method according to the invention. According to a fourth aspect of the invention, a computer-readable medium is provided, on which the computer program according to the invention is recorded. The invention and its various applications will be better understood upon reading the following description and examining the accompanying figures. BRIEF DESCRIPTION OF THE FIGURES The figures are presented for information purposes only and in no way limit the invention. [Fig.1] shows a schematic representation of a system for the implementation implementation of the prior art MCData IPCON service. [Fig.2] is a block diagram illustrating the sequence of steps of the method according to the invention. Figures 3 and 4 are block diagrams illustrating the sequence of steps of the method according to two variants of the invention. [Fig.5] shows a schematic representation of a configured system for the implementation of the MCData IPCON service according to the invention. [Fig.6] shows a schematic representation of a configured system for the implementation of the group MCData IPCON service in a mode implementation of the invention. DETAILED DESCRIPTION Unless otherwise specified, the same element appearing in different figures has a single reference. [Fig. 5] is a schematic representation of a method for establishing an MCData IPCON “Mission Critical Data IP Connectivity” session according to the invention. The sending MCData entity 320 and the receiving MCData entity 370 are connected 350 to the MCData transport service 330. The MCData transport service 330 comprises one or more MCData servers. The sending MCData entity 320 is connected to a sending application entity 310. The sending application entity 310 is for example a sending application server. The receiving MCData entity 370 is connected to a receiving application entity 360. The receiving application entity 360 is for example a receiving application server. The IP tunnel 340 allows the IP routing of data 300, in particular media data from the sending application entity 310 to the receiving application entity 360 via the MCData entities 320 and 370. The communication network of [Fig.5] is configured to implement the MCData IPCON service. The MCData sender 320 and recipient 370 entities are interchangeable, that is to say that an MCData entity can be sender 320 over one period and then recipient 370 over another period. Each of these MCData entities has an identity within the communication network. This identity makes it possible to identify the entity within the communication network. For example, the identity can be a unique identifier within the communication network. [Fig.2] is a block diagram illustrating the sequence of steps of the method according to the invention. In a first step 20, the sending MCData entity 320 obtains a DPPK key (MCData Payload Protection Key) and a DPPK-ID key identifier (MCData Payload Protection Key Identifier). Obtaining the DPPK key may consist of receiving the DPPK key and the DPPK-ID identifier. Obtaining the DPPK key may also consist of generating the DPPK key using the encryption elements. It should be noted that the DPPK key is not a particular type of key. Indeed, the term DPPK groups together the types of keys existing in MCData, for example a PCK private key (Private Call Key) and a GMK key (Group Master Key), used for protection in the MCData method respectively for point-to-point communications and for group communications. Consequently, several DPPK keys may be used in a method 1 for establishing an MCData IPCON session depending on the communication channel.Additionally, although both a PCK private key and a GMK can be used as a DPPK key to protect the MCData process in different channels, the PCK private key and the GMK are not the same key and will not be used in the same channels. The method 1 according to the invention comprises a second step of transmission 30, by the sending MCData entity 320 to the receiving MCData entity 370 via the MCData transport service, of a SIP-INVITE message comprising the DPPK key and the identifier of the DPPK-IK key. Transmission 30 is performed using the SDP (Session Description Protocol). SDP is a communication protocol for describing the initialization parameters of a streaming session. SDP does not include media delivery. It is used by the sender and receiver to negotiate the media type and format, and associated properties. Transmission 30 is performed by embedding an SDP payload in the body of a SIP INVITE message. The SIP INVITE message is sent by the MCData entity. sending entity 320 to the receiving MCData entity 370. The receiving MCData entity 370 then responds whether or not it accepts the establishment of an MCData IPCON session with the sending MCData entity 320. In a third step 40, the recipient MCData entity 370 authenticates the SIP-INVITE message. The purpose of authentication is to verify that the SIP-INVITE message actually comes from the sending MCData entity and that it is not corrupted. Authentication can be facilitated by authentication procedures carried out prior to the implementation of the method according to the invention. Thus, in this case, authentication can consist of verifying that the message was actually sent by the sending MCData entity. Authentication can also consist of verifying the signature of an element contained in the message. The validity of the signature can be determined by verifying that the identity of the sending MCData entity 320 exists in the list of trusted identities of the receiving MCData entity 370 and the integrity of the document. The method 1 according to the invention comprises a final step of determination 50, by the recipient MCData entity 370, of the DPPK key and the identifier of the DPPK-ID key. [Fig. 3] is a block diagram illustrating the sequence of steps of the method according to a variant of the invention. In this variant, the method further comprises final steps 60, 70, 80, 90 and 100. This variant allows the secure end-to-end sending of data between two application entities. Each application entity is for example an application server. A first application entity 310 is connected to a sending MCData entity 320 and a second application entity 360 is connected to a receiving MCData entity 370. In step 60, the sending application entity 310 transmits useful data to the sending MCData entity 320. This useful data may or may not be encrypted. Then, the sending MCData entity 320 generates at a step 70 a data packet comprising the encrypted payload data using the DPPK key and the key identifier DPPK-ID and a header. Thus, before the generation 70, the payload data is encrypted. In order to perform the encryption, a derivation of the DPPK key may be necessary. For example, the DPPK key is hashed by a key derivation function to produce a DPCK encryption key “MCData Payload Cipher Key” of the payload data. An example of a protected data format compatible with the invention is described in clause 8.5.4.1 in the technical specifications document TS 33.180 of the 3GPP standard. Step 80 consists of sending, by the sending MCData entity 320, the generated data packet 70 to the receiving MCData entity 370. The receiving MCData entity 370 then removes in a step 90 the header of the data packet generated in step 70 and decrypts the encrypted useful data using the DPPK key and the identifier of the DPPK-ID key. Finally, the receiving MCData entity 370 transmits in a step 100 the decrypted useful data to the recipient application entity 360. It should be noted that the MCData servers of the MCData transport service 330 ensure the transport between the sending MCData entity 320 and the recipient MCData entity 370. These MCData servers may in particular use the header of the data packet generated in step 70 to identify the recipient MCData entity 370. In a variant compatible with the variant described above, the IP tunnel 340 is a GRE “Generic Routing Encapsulation” tunnel in the UDP “User Datagram Protocol” protocol and the header is a GRE and UDP type header. The GRE tunnel in UDP is configured between the sending MCData entity 320 and the receiving MCData entity 370, each MCData entity 320 and 370 acting as an endpoint of the IP tunnel 340. The MCData entities 320 and 370 are configured to send and receive the GRE packets directly between them. The MCData servers of the MCData transport system 330 located between these two MCData entities 320 and 370 will not open the encapsulated data packets. They will only refer to the headers surrounding the encapsulated packets in order to be able to transmit them. Thus, this encapsulation makes it possible in particular not to affect the security of the encapsulated data packets. [Fig.4] is a block diagram illustrating the sequence of steps of the method according to a variant of the invention. In this variant, compatible with the preceding variants, the method further comprises the preliminary steps 110 and 120. In step 110, the sending MCData entity 320 and the receiving MCData entity 370 obtain 110 information authorizing the establishment of an MCData IPCON session, configured with an MCData media plan, between the sending MCData entity and the receiving MCData entity 370 and information concerning the need to implement a method ensuring the security of the data sent. The information concerning the need to implement the method ensuring the security of the data sent can therefore be used to activate or deactivate the implementation of the method, for example, depending on the security of the data applied by the application servers.The MCData IPCON service provides a media plane for the exchange of any type of IP data between IP applications. These IP applications can reside on hosts external to the 3GPP network connected by an IP interface to the MCData entity or can be executed directly by the MCData entity. A media plane that can be used in the invention is detailed in the technical specifications document TS 24.582. The information on the authorization of MCData IPCON session establishment and on the need to implement the method ensuring the security of the sent data can be inserted in the profile document of the sending and receiving MCData entities. Depending on this information, the method is implemented at a step 120 or not. Thus, if the information authorizes the establishment of an MCData IPCON session, configured with an MCData media plan, between the sending MCData entity 320 and the receiving MCData entity 370 and confirms the need to implement the method ensuring the security of the data sent, then the method according to the invention is implemented in a step 120. In a first embodiment, the method according to the invention is a method for establishing a group MCData IPCON session. The sending MCData entity is a sending MCData client 420 belonging to an MCData group 480, the receiving MCData entity is a set of receiving MCData clients 470 belonging to the same MCData group 480 as the sending MCData client 420, the DPPK key is a key of the GMK “Group Master Key” type and the identifier of the DPPK-ID key is of the GMK-ID “Group Master Key Identifier” type. In this first implementation mode, the GMK key and the GMK-ID key identifier are obtained in step 20. This obtaining by the issuing MCData entity consists of receiving the GMK key and the GMK-ID key identifier. The GMR key and the GMK-ID key identifier can be provided by a GMS “Group Master Server”. In step 30, the transmission of the container is carried out from a sending MCData client 420 to the other members of the group which are therefore receiving MCData clients 470. Then, in step 40, each recipient MCData client authenticates the SIP-INVITE message by verifying that the container originates from the client belonging to the same group. In this first implementation mode, authentication is facilitated by authentication procedures carried out prior to the implementation of the method according to the invention. Thus, in this case, authentication may consist of verifying that the message has indeed been sent by the sending MC Data entity, for example by accessing a sub-element of the group document which contains all the information relating to the group. Finally, in step 50, the recipient MCData client determines the GMK key and the GMK-ID key identifier. For example, the SIP-INVITE message may contain a group identifier, for example a “Uniform Resource Locator” URL address, which allows access to a group document containing the GMK and GMK ID. Once the group communication session is established, a sending MCData client that wishes to transmit a data packet to the other members of the group must encrypt this data packet. An example of encryption that can be used in the invention is that described in the technical specification document TS 33.180, including a derivation of the GMK key as defined in clause 8.5.3 and a protected data format described in clause 8.5.4.1 in the technical specification document TS 33.180, before adding the necessary headers. An example of a usable header is a GRE and UDP header. Then, optionally, Recipient MCData clients 470 perform the reverse operation before forwarding the decrypted packet to the intended data host. [Fig. 6] is a schematic representation of a system that can be used to implement this first implementation mode. The sending MCData client 420 and the receiving MCData clients 470 belong to the same MCData group 480. Each MCData client 420 and 470 is connected 450 to the MCData transport service 430. The MCData transport service 430 comprises one or more MCData servers. The MCData client 420 is connected to a sending application entity 410. Each receiving MCData client 470 is connected to a receiving application entity 460. The IP tunnel 440 allows the IP routing of data 400, in particular media data, from the application entity 410 to the application entities 460. In a second embodiment, the method according to the invention is a method for establishing a point-to-point MCData IPCON session. The sending MCData entity 320 and the receiving MCData entity 370 are MCData clients. The DPPK key is a private key of the PCK “Private Call Key” type and the identifier of the DPPK-ID key is of the PCK-ID “Private Call Key Identifier” type. In the first step 10, the MCData clients sender 320 and recipient 370 obtain encryption elements. These encryption elements allow obtaining and determining the PCK key and the identification of the PCK-ID key. These encryption elements can be provided by a KMS server "Key Management Server". The encryption elements coming from the KMS server are for example the private key SSK "Secret Signing Key", the public key "PVT" "Public Validation Token" or the public authentication key KPAK "KMS Public Authentication Key". In the second step 20, the sending MCData client obtains a private key PCK and a private key identifier PCK-ID. This obtaining consists of generating the private key PCK and the private key identifier PCK-ID using the encryption elements obtained in step 10. In order to perform the encryption, a derivation of the PCK key may be necessary. An example of derivation usable in the invention is defined in clause 8.3 of the technical specifications document TS 33.180. The PCK key obtained in step 20 includes the encryption of the identity of the recipient MCData entity 370. Thus the PCK key makes it possible, after extraction, to obtain the recipient MCData entity 370. In the third step 30, the sending MCData transmits the private key PCK and the private key identifier PCK-ID in the SIP-INVITE message. The SIP-INVITE message includes a MIKEY-SAKKE I-MESSAGE container “Multimedia Internet KEYing-Sakai-Kasahara Key Encryption”, the MIKEY-SAKKE I-MESSAGE container including the DPPK key encrypted with an encryption method SAKKE; and the key identifier DPPK-ID. The MIKEY-SAKKE I-MESSAGE container is used in particular to transport the DPPK key. The DPPK key can for example be 16 bytes long. The DPPK key is encapsulated in the container with a SAKKE encryption method. An example implementation of MIKEY-SAKKE I-MESSAGE messages suitable for implementing the invention is defined in the IETF RFC 6509 document “Internet Engineering Task Force Request for Comments: 6509”. Authenticating the SIP-INVITE message can involve validating the signature of the SIP-INVITE message. Signing the SIP-INVITE message involves signing the container. The signed container allows the receiving MCData client to authenticate the container by validating the signature. For example, the container is signed using a signature that authenticates the origin of the container by the receiving MCData client. The container is transmitted from a sending MCData client to a receiving MCData client. The MIKEY-SAKKE I-MESSAGE message includes the private key PCK. An example of a possible structure of the MIKEY-SAKKE I-MESSAGE message for this embodiment is described in Annex E.3 in the technical specification document TS 33.180. In the fourth step 40, the receiving MCData client authenticates the container comprising the MIKEY-SAKKE I-MESSAGE message by validating the caller's signature. In the fifth step 50, the recipient MCData client determines the private key PCK and the private key identifier PCK-ID. The determination is performed by extraction using the encryption elements obtained in step 10 Subsequent traffic on the established MCData IPCON session, i.e. the content sent by a sending application entity to another receiving application entity, is encrypted by the sending MCData client and decrypted by the receiving MCData using the PCK key. An example of encryption and decryption that can be used for an implementation of the invention is described in the technical specification document TS 33.180, including a derivation of the PCK key as defined in clause 8.5.3 and a protected data format described in clause 8.5.4.1 in the technical specification document TS 33.180, before adding the necessary headers. This encrypted content is transported in the tunnel established between the two MCData clients, for example a GRE in UDP tunnel.So, after encrypting the content received from the sending application entity, the sending MCData client adds a header for example a GRE and UDP header before transmitting the data packet to the receiving MCData client, which removes these added headers before decrypting the content and then transmitting the decrypted content to the receiving application entity.

Claims

Claims

1. Method (1) for establishing MCData IPCON session “Mission Critical Data Internet Protocol Connectivity” in a communication network communication according to the 3GPP MCS standard “3rd Generation Partnership Program Mission Critical System”, the network comprising: an issuing MCData entity; a recipient MCData entity; and an MCData transport service connected to MCData entities sender and recipient; the method comprising: Obtain (20), by the issuing MCData entity, a DPPK key “MCData Payload Protection Key” and a key identifier DPPK-ID “MCData Payload Protection Key Identifier”; Transmit (30), by the sending MCData entity to the entity MCData recipient via the MCData transport service, a SIP-INVITE message including the DPPK key and identifier of the DPPK-IK key; Authenticate (40), by the recipient MCData entity, the message; and Determine (50), by the recipient MCData entity, the key DPPK and the key identifier DPPK-ID and establish an IP tunnel. between the issuing MCData entity and the des- MCData entity recipient.

2. Method (1) according to claim 1 in which the MCData entity transmitter is connected to a transmitter application entity and the entity MCData recipient is connected to at least one application server des- recipient, the method further comprising the final steps: Transmit (60), by the sending application server, data useful to the issuing MCData entity. Generate (70), by the sending MCData entity, a packet of data including: the payload encrypted using the DPPK key and the DPPK-ID key identifier; and a header; Send (80), by the sending MCData entity, the packet of data generated (70) to the recipient MCData entity via the JP tunnel established; Remove (90), by the recipient MCData entity, the header of the generated data packet (70) and decrypt the payload encrypted using the DPPK key and key ID DPPK-ID; and Transmit (100), by the recipient MCData entity, the decrypted useful data to at least one application entity.

3. A method according to claim 2 wherein: The IP tunnel is a GRE tunnel “Generic Routing Encap- sulation" in the UDP "User Datagram" protocol Protocol" ; and The header is a GRE and UDP type header.

4. A method according to any preceding claim. further including the preliminary steps: Obtain (110) information: MCData session establishment authorization IPCON, configured with an MCData media plan, between the issuing MCData entity and the MCData entity recipient; and of the need to implement the process according to any one of the preceding claims; and Implementing (120) the method of claim 1 when MCData IPCON session establishment, configured with the MCData media plan, between the issuing MCData entity and the recipient MCData entity is authorized and if the implementation of the method according to any one of the preceding claims previous is necessary.

5. A method according to any preceding claim in which : Said method is a session establishment method MCData IPCON group; The issuing MCData entity is an MCData client belonging to an MCData group; The recipient MCData entity is a set of clients MCData belonging to the same MCData group as the entity MCData transmitter; and The DPPK key is a GMK “Group Master Key” type key. and the DPPK-ID key identifier is of type GMK-ID “Group Master Key Identifier”.

6. Method according to claims 1 to 4 in which: Said method is a session establishment method MCData IPCON point to point; The sending MCData entity and the receiving MCData entity are MCData customers; and The DPPK key is a private key of the PCK type “Private Call Key”, the key identifier DPPK-ID is of type PCK-ID “Private Call Key Identifier” and the PCK key including the encryption of the identity of the recipient MCData entity; An initial step of obtaining (10), by the MCData entity issuer and the recipient MCData entity, elements of encryption; Obtaining at step (20), by the issuing MCData entity, the PCK key and PCK-ID key identifier consists of a generation of the PCK key and the PCK-ID identifier in using the encryption elements obtained in step (10); The SIP-INVITE message transmitted in step (30) by the entity MCData sender to MCData recipient entity, includes a MIKEY-SAKKE I-MESSAGE container “Multimedia Internet KE Ying-Sakai-Kasahara Key Encryption”, the MIKEY-SAKKE I-MESSAGE container including the key DPPK encrypted with a SAKKE encryption method;: and the DPPK-ID key identifier; and The determination (50) by the recipient MCData entity, of the PCK key and PCK-ID key identifier is performed in using the encryption elements obtained in step 10.

7. Communication network according to the 3GPP MCS standard “3rd Ge- Neration Partnership Program Mission-Critical System”, the network of communication including: An issuing MCData entity; A recipient MCData entity; and An MCData transport service connected to MCData entities sender and recipient; the communication network being configured to implement the method (1) according to any one of the preceding claims.

8. Network according to the preceding claim characterized in that the entity MCData recipient is: A set of MCData clients belonging to the same group MCData that the issuing MCData entity; or Unclient MCData.

9. Computer program product comprising instructions which lead the network according to claim 8 to execute the steps of the method according to one of claims 1 to 6.

10. Computer-readable medium on which the program is recorded computer according to claim 9.