Method for managing encryption by a sending entity in a 3GPP MCS network

Abstract

TITLE: Method for managing encryption by a sending entity in a 3GPP MCS network. One aspect of the invention relates to a method implemented by a sending client entity within a network conforming to the 3GPP MCS standard, the sending client entity being configured to send content intended for a receiving client entity within the network and affiliated with the same communication group. The method comprises at least one step of selecting a security context from among: A security context with end-diversity consisting of: A long master key identifier consisting of the GMK-ID and the DMK-ID, or A short master key identifier consisting of the GMK-ID, or A short master key identifier consisting of the GUK-ID, or No master key identifier. A security context without end-diversity consisting of: A short master key identifier consisting of the GMK-ID, or No master key identifier. Figure to be published with the abstract: Figure 1

Description

Title of the invention: Method for managing encryption by a transmitting entity in a 3GPP MCS network 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 managing encryption by a transmitting entity in a 3GPP MCS network, and in particular making it possible to manage cases not provided for by the standard. TECHNOLOGICAL BACKGROUND OF THE INVENTION

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

[0004] These networks are evolving towards support for broadband exchanges. The 3GPP standard governing mobile networks of the “GSM” type according to the Anglo-Saxon term “Global System for Mobile Communications” and more particularly in deployments using critical communications services defined by the 3GPP called “MCS” according to the Anglo-Saxon term “Mission Critical Services” allows these secure broadband exchanges.

[0005] The encryption of MCPTT (Mission Critical Push To Talk) or MCVideo voice media in a group communication is defined in the technical specification TS 33.180. It notably implements endpoint diversity.

[0006] Hereinafter, any Mission-Critical service defined by the 3GPP MCS standard will be called “MCX”, such as the MCVideo, MCData (for “Data” in French) and MCPTT services. A “client” and a server are devices comprising at least one processor and a memory, the memory comprising instructions which, when executed by the processor, cause the user device to implement at least the actions assigned to it. Preferably, a client is a user device. Similarly, a “server” can be a user device. An “MCX client” and an “MCX server” are therefore user devices configured to implement Mission-Critical services.

[0007] When transmitting media from an MCX client, the transmitted media can be encrypted in a way that is independent of the transmitter. In such a case, the concept of "endpoint diversity" is not implemented. On the contrary, the implementation of endpoint diversity requires the encryption of the transmitted media by a key specific to the transmitting MCX client. For this, the MCX ID identity of the user of this transmitting MCX client is used to generate a group user key identifier (GUK-ID for "Group User Key Identifier" in English). This GUK-ID identifier is used for: • encrypt a media of the SRTP stream (from the English “Secure Real-time Protocol” for “Protocol Temps Réel Sécurisé” in French) sent by the MCX client sender and • decrypt this SRTP media stream by the receiving MCX clients.

[0008] The procedures of the technical specification TS 33.180 (clause 7.4.2) require the sending MCX client to include this GUK-ID identifier in a 64-bit SRTP MKI (Master Key Identifier) ​​field transmitted with each SRTP packet. The long format (64-bit) MKI master key identifier actually includes a group master key identifier (GMK-ID) concatenated with the group user key identifier GUK-ID. To create the security association of the communication group within which the media is exchanged, a group master key (GMK) and its associated identifier (GMK-ID) are distributed to the MCX clients in the group by a group management server (GMS).

[0009] This procedure also provides the possibility, when the identity of the user of the sending MCX client (identity also called "User Sait" in English) is known to the receiving MCX clients, to reduce the SRTP MKI to 32 bits by omitting its GUK-ID component of the sender, i.e. by only including the group master key identifier GMK-ID. The group user key identifier GUK-ID is then calculated locally by the receiving MCX clients by performing an "exclusive OR" XOR operation between the known identity of the sending MCX client user ("User sait") and the group master key identifier GMK-ID. In the same way, the group master key identifier GMK-ID can be calculated from the group user key identifier GUK-ID and the known identity of the sending MCX client user ("User sait").On the other hand, the identity of the sending MCX client user cannot be obtained from the group master key identifier GMK-ID and the group user key identifier GUK-ID, in order to maintain a certain confidentiality.

[0010] The identity of the user of the sending MCX client can be obtained because it is included in the floor control messages in MCPTT voice service, messages called “Floor Control”. In MCVideo video service, this information is obtained because it is included in the transmission control messages, messages called "transmission control". In MCData service, there is no endpoint diversity in the 3GPP specifications. In MCData, however, it is possible to recover the identity of the user of the sending MCX client in the payload of SIP and / or HTTP messages. SIP is a well-known Session Initiation Protocol and HTTP (for "HyperText Transfer Protocol") is a well-known communication protocol. In MCData, this payload is end-to-end encrypted but without endpoint diversity.

[0011] In the 3GPP MCS standard, only the sending MCX client determines which MKI identifier format (32 bits or 64 bits) it uses. Its user identity is transmitted in all call setup requests and in all floor requests and transmission control requests.

[0012] The sending MCX client can therefore legitimately consider that its user identity is transmitted from end to end and choose to save bandwidth (from 5 to 10% for MCPTT voice depending on the header compression used) by using the reduced MKI format (32 bits) not including its GUK-ID identifier, then considering that the receiving MCX clients will be able to recalculate it locally using its user identity recovered from the floor control, transmission control or SIP messages in MCData.

[0013] However, there are cases where the identity of the user of the sending MCX client cannot be known to all or some receiving MCX clients, preventing them from being able to decrypt the information received, without the sending MCX client knowing: • Because in accordance with the procedures of technical specifications TS 24.380 (“media plane” MCPTT) and 24.581 (“media plane” MCVideo), the media controller server of the group within which users communicate considers that there is a need for privacy and that the identity of the user to whom the right to transmit is granted must not be indicated to other participants, or • Because in accordance with the procedures of technical specifications TS 24.380 and 24.581 for grouped groups, the identity of the user requesting the right to transmit is hidden from the media controller server of the group group by the media controller server of the constituent group (called "Non-controlling server"), the constituent group being the communication group belonging to the grouped group and to which the user device of the user requesting the right to transmit is affiliated, • Because in the case of interconnected systems, the identity of users of one of the systems may be considered sensitive and masked by an MCX gateway server in charge of filtering such sensitive information in messages exchanged between systems that do not fully trust each other. In such a context, the scope of the communication group (intra or inter system) is not necessarily known to the members of the group.

[0014] According to the 3GPP TS 33.180 technical specification, there is a need to encrypt media in the communication group using endpoint diversity. This is only valid for voice media (MCPTT) and video media (MCVideo) but not for MCData payloads, because there is no endpoint diversity in the 3GPP MCS specifications of MCData.

[0015] As described above, since the identity of the user of the sending MCX client cannot always be known to other participants, for example for reasons of confidentiality (privacy), in cases of interconnection of systems in different trust domains, or in cases of group grouping, there are currently cases in which the receiving MCX clients cannot decrypt the received media, whether it is voice media (MCPTT), video media (MCVideo). The confidentiality requirement of the sending MCX client can be determined at any level, for example per call, per user, per group, per organization, per system or per country, which complicates the task of identifying, in a network, the actors and / or actions that may be required to hide the identity of the user of the sending MCX client.

[0016] There is therefore a need to be able to ensure, in a 3GPP MCS network, that a receiving MCX client can decrypt encrypted content sent by a sending MCX client. Summary of the invention

[0017] The invention provides a solution to the problems mentioned above, by allowing a transmitting client, in a 3GPP MCS network, to choose the encryption that it applies to transmitted content so that a receiving client can properly decrypt the transmitted content.

[0018] One aspect of the invention relates to a method implemented by a transmitting client entity included in a network according to the 3GPP MCS “3rd Generation Partnership Program Mission Critical Services” standard, the transmitting client entity being configured to transmit content intended for a receiving client entity included in the network, the transmitting client entity and the receiving client entity being affiliated with the same communication group, the method comprising at least one step of selection, by the transmitting client entity from at least one security context information stored in the memory of the transmitting entity, of a security context from among the following security contexts: • A security context with end diversity, the security context being formed of: • A long MKI master key identifier formed from a group master key identifier GMK-ID and a group user key identifier GUK-ID, the group master key identifier GMK-ID being specific to the communication group, the group user key identifier GUK-ID being specific to a user of the issuing entity, or • A short MKI master key identifier formed from the group master key identifier GMK-ID or • A short MKI master key identifier formed from the group user key identifier GUK-ID or • No MKI master key identifier. • A security context without end diversity, the security context being formed of: • A short MKI master key identifier formed from the group master key identifier GMK-ID or • No MKI master key identifier.

[0019] Thanks to the invention, it is ensured that the entity receiving content transmitted and encrypted by a transmitting entity is capable of decrypting the content. For this, the invention comprises a selection of a security context as a function of information stored in the memory of the transmitting entity. Thus, the transmitting entity is aware of the environment in which it transmits the encrypted content and the security context comprises the information necessary for the receiving entity to be able to decrypt the content. Furthermore, the security context can be used to adapt the encryption of the content and allows a dynamic selection of encryption contrary to what the 3GPP MCS standard currently provides in the technical specification TS 33.180. The invention allows the transmitting entity to use or not use endpoint diversity, contrary to what the 3GPP MCS standard currently provides in the technical specification TS 33.180, which saves bandwidth by not having to transmit the group user key identifier GUK-ID in the master key identifier MKI.

[0020] The inventors also noted that the group master key identifier GMK-ID sometimes does not need to be transmitted, the receiving entity being able to determine which group master key identifier GMK-ID was used from the key identifiers GMK-ID group master that it already stores, for this communication group within which it receives the encrypted content or for all communication groups to which it is affiliated. Without the invention, it is not possible to implement this type of case, in which the master key identifier MKI does not need to be sent with the encrypted content, because it is not provided for by the 3GPP MCS standard, and because there is no mechanism allowing it. The presence of security context information in the memory of the sending entity makes it possible to select a security context to implement this type of case.

[0021] Thanks to the invention, the network bandwidth is not unnecessarily used, by sending only the information necessary for the receiving entity to be able to decrypt the content, and all the necessary information is sent so that the receiving entity can decrypt the content.

[0022] In cases where the identity of the user of the sending entity is not known to the receiving entity, a security context with a short master key identifier MKI comprising the identifier of the group user key GUK-ID may be selected, because the receiving entity can then determine the correct group master key identifier GMK-ID by testing the different group master key identifiers GMK-ID that it stores and therefore decrypt the content using the master key composed of the received group user key identifier GUK-ID and the determined group master key identifier GMK-ID, without having to use the identity of the user of the sending entity.

[0023] In addition to the characteristics which have just been mentioned in the preceding paragraphs, the method according to one aspect of the invention may have one or more complementary characteristics among the following, considered individually or according to all technically possible combinations: • the method further comprises the steps of: • Content encryption, the content being encrypted by the sending client entity, the content encryption being based on a master key according to the SRTP (Secure Real Time Protocol) protocol, the master key being obtained: • If the security context is with endpoint diversity, from the group master key identifier (GMK-ID) and the group user key identifier (GUK-ID), • If the security context is without end diversity, from the group master key identifier (GMK-ID), • Sending a frame to the receiving entity, according to the SRTP protocol, the frame including the encrypted content and the security context. • the information stored in the memory of the issuing entity is a set of parameters including the following parameters: • End diversity parameter including information on whether or not end diversity is implemented, • Group master key identifier (GMK-ID) transmission parameter including information on whether or not the group master key identifier (GMK-ID) is transmitted, • Group user key identifier (GUK-ID) transmission parameter including information on whether or not the group user key identifier (GUK-ID) is transmitted, and that the security context is constructed from the set of parameters. • the communication group is an MCPTT, MCVideo or MCData group. • security context information is received from a remote entity prior to the security context selection step. • the group master key identifier GMK-ID can be obtained from the group user key identifier GUK-ID and an identity of the user of the issuing entity and the group user key identifier GUK-ID can be obtained from the group master key identifier GMK-ID and an identity of the user of the issuing entity.

[0024] 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 at least: • an issuing client entity configured to implement the method according to the invention, • a receiving client entity configured to receive the encrypted content and security context issued by the sending entity.

[0025] 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

[0026] The figures are presented for information purposes only and in no way limit the invention. • [Fig.l] shows a schematic representation of a network comprising entities configured to implement the method according to the invention, • Figures 2a to 2d show different schematic representations of selectable security contexts, • [Fig.3] shows a schematic representation of a method according to the invention. • [Fig.4] shows a schematic representation of a transmitting entity configured to implement the method according to the invention. DETAILED DESCRIPTION

[0027] Unless otherwise specified, the same element appearing in different figures presents a unique reference.

[0028] [Fig.l] shows a schematic representation of a network comprising entities configured to implement the method according to the invention.

[0029] In particular, the network represented in [Fig.l] comprises a transmitting entity E configured to implement the method according to the invention, and a receiving entity R.

[0030] The network shown in [Fig.l] is a network according to the 3GPP MCS standard, that is to say it is implemented following the specifications defined by the 3GPP MCS standard.

[0031] [Fig. 3] shows a schematic representation of the method according to the invention. The method shown in [Fig. 3] is a method for managing encryption according to the invention within the network of [Fig. 1].

[0032] The network of [Fig.l] comprises a communication group G. The transmitting entity E is affiliated with the communication group G. The receiving entity R is also affiliated with the same communication group G. The group G is an MCPTT, MCVideo or MCData communication group as defined in the state of the art.

[0033] The sending entity E and the receiving entity R may be client or server entities, participating or non-participating, or any other entity defined by the 3GPP MCS standard. The sending entity E and the receiving entity R are devices comprising at least one processor and a memory, the memory comprising instructions which, when executed by the processor, cause the processor to implement an action attributed to the entity. For example, the entities may be user devices such as mobile phones, tablets, computers, or any other device usable by a user, or may also be computers or devices having the role of server within the meaning of the 3GPP MCS standard.

[0034] The method 1 according to the invention represented in [Fig. 3] allows the transmitting entity E to select a security context S appropriate with regard to the network in which it operates. For this, the transmitting entity E stores at least one security context information I, on the basis of which it carries out a step 12 of selecting a security context S, the selection step 12 being included in the method 1 according to the invention represented in [Fig. 3].

[0035] The security context information I is stored in the memory (not shown) of the transmitting entity E. This information may optionally have been received, at a reception step 11 included in the method 1 according to the invention shown in [Fig.3]. This reception step 11 may comprise the reception, via the 3GPP MCS network, of the information I having been sent by a remote entity, for example by a server or by a client entity controlled by a user, for example by an administrator having knowledge of the 3GPP MCS network. This information I has preferably been created by the administrator having knowledge of the 3GPP MCS network and its specificities, in order to subsequently have a selection of security context S at step 12 of the method 1 that is as appropriate as possible in relation to the topology and the context of the network.

[0036] In a preferred embodiment shown schematically in [Fig.4], the security context information I comprises a set of parameters. This set of parameters preferably comprises the following three parameters: • DE end diversity parameter including end diversity implementation information or not, • TGMK transmission parameter of the GMK-ID group master key identifier including information on whether or not the GMK-ID group master key identifier is transmitted, • TGUK transmission parameter of the group user key identifier GUK-ID including information on whether to transmit the group user key identifier GUK-ID or not.

[0037] The invention uses the following key identifiers: • Group user key identifier GUK-ID: this identifier is a key identifier specific to a user of the sending entity E and specific to the communication group G. Thus, this key can be seen as a “session key” in the SRTP protocol, as defined in RFC 3711. An identifier of this key, which does not have to remain secret, makes it possible to retrieve this key, which must remain secret. In the absence of endpoint diversity, this user key is not used to encrypt content in the 3GPP MCS standard. • Group Master Key Identifier GMK-ID: This identifier is a group master key identifier specific to communication group G. In the absence of endpoint diversity, this group master key GMK is used alone to encrypt content in the 3GPP MCS standard, as defined in point 7.5.1 of technical specification TS 33.180. In the presence of endpoint diversity, this group master key GMK is used in combination with the group user key GUK to encrypt content as defined in point 7.4.2 of technical specification TS 33.180. • MKI Master Key Identifier: This identifier is a master key identifier.

[0038] Each of the three parameters DE, TGMK and TGUK can be represented in any form, for example in the form of a character string or a Boolean. These three parameters are preferably given a value, i.e. a “yes” indication or a “no” indication, by a user and preferably again by an administrator of the 3GPP MCS network.

[0039] The method 1 according to the invention comprises at least one step 12 of selecting a security context S. This security context S is intended to be transmitted, in a step 14 of the method 1, in the header of a frame T also comprising the encrypted content C, as represented in [Fig.l].

[0040] Depending on the end diversity parameter DE, the security context S is selected from one of the following two groups: • A security context S with end diversity or • A security context S without end diversity.

[0041] In some cases, it may be desired to do without end diversity, which the present invention allows, unlike the 3GPP MCS standard. Indeed, end diversity does not provide additional security and complicates bandwidth optimization if the identity of the transmitter is not easy to obtain.

[0042] In the case where a security context S with end diversity is chosen, the group user key identifier TGUK and group master key identifier TGMK parameters then make it possible to select a security context S formed of: • A long MKI master key identifier formed from the group master key identifier GMK-ID and the group user key identifier GUK-ID if both parameters TGMK and TGUK include an indication to use the group master key identifier GMK-ID and the group user key identifier GUK-ID respectively, or • A short MKI master key identifier formed from the group master key identifier GMK-ID if the TGMK parameter includes an indication to use the group master key identifier GMK-ID and if the TGUK parameter includes an indication not to use the group user key identifier GUK-ID or • A short MKI master key identifier formed from the group user key identifier GUK-ID if the TGMK parameter includes an indication not to use the group master key identifier GMK-ID and if the TGUK parameter includes an indication to use the group user key identifier GUK-ID or • No MKI master key identifier if the TGMK parameter includes an indication not to use the GMK-ID group master key identifier and the TGUK parameter includes an indication not to use the GUK-ID group user key identifier.

[0043] “Short MKI” means a master key identifier MKI with a length of 32 bits because it only includes the GUK-ID or the GMK-ID, and “long MKI” means a master key identifier MKI with a length of 64 bits because it includes the GUK-ID and the GMK-ID.

[0044] In a security context S with end diversity and with long master key identifier MKI, case represented in [Fig.2a], the encryption and decryption method is the default one defined by the 3GPP MCS standard in the technical specification TS 33.180.

[0045] In a security context S with endpoint diversity and with short master key identifier MKI comprising the group master key identifier GMK-ID, case shown in [Fig.2b], the encryption and decryption method is that defined by the 3GPP MCS standard in the technical specification TS 33.180 in which the receiving entity R knows the identity of the user of the sending entity E. It is applicable only in the cases of MCX configuration guaranteeing that the identity of the sending entity E will be received by all the receiving entities of the communication group and is thus the responsibility of the configuration administrator when it is the latter who determines the parameters included in the security context information I stored in the memory of the sending entity E. These parameters can be updated and modified, by a remote entity or by the sending entity E itself.

[0046] In a security context S with endpoint diversity and with short master key identifier MKI comprising the group user key identifier GUK-ID, a case not existing in the 3GPP MCS standard and represented in [Fig.2c], the group master key identifier GMK-ID must then be determined by the receiving entity R. This is achieved by means of a step not shown implemented by the receiving entity R after receiving the frame T. In this step, included in a content transmission method according to the invention implemented by the transmitting entity E and by the receiving entity R and previously comprising the steps of method 1 according to the invention, the group master key identifier GMK-ID is determined by testing all the group master keys known to the receiving entity R. Indeed, the encryption mode specified by the technical specification TS 33.180 is AEAD-AES-128-GCM, which checks integrity, and therefore it is not possible for the receiving entity R to determine the wrong GMK group master key because integrity is only checked for the correct GMK group master key. All associated GMK group master keys. to the communication group G stored by the receiving entity R or all group master keys GMK stored by the receiving entity R can be tested.

[0047] In a security context S with endpoint diversity and without master key identifier MKI, a case that does not exist in the 3GPP MCS standard, the security context S that will be included in the frame T is empty (0 bits), as shown in [Fig.2d]. The group master key identifier GMK-ID must then be determined by the receiving entity R. This is achieved by means of a step (not shown) implemented by the receiving entity R after receiving the frame T. In this step, included in a content transmission method according to the invention implemented by the transmitting entity E and by the receiving entity R and previously comprising the steps of method 1 according to the invention, the group master key identifier GMK-ID is determined by testing all the group master keys known to the receiving entity R. Indeed, the encryption mode specified by the technical specification TS 33.180 is AEAD-AES-128-GCM, which verifies the integrity, and it is therefore not possible for the receiving entity R to determine the wrong group master key GMK. All group master keys GMK associated with the communication group G stored by the receiving entity R or all group master keys GMK stored by the receiving entity R can be tested. Once the group master key identifier GMK-ID is determined, the group user key identifier GUK-ID can be determined based on the identity of the user of the sending entity E, as in the prior art.

[0048] In a security context S without end diversity, the security context S can be formed from: • A short master key identifier MKI formed from the group master key identifier GMK-ID, case shown in [Fig.2b], or • No MKI master key identifier, case shown in [Fig.2d].

[0049] Indeed, in a security context S without end diversity the group user key identifier is not used to encrypt the content C.

[0050] In a security context S without end diversity and without master key identifier MKI, a case not existing in the 3GPP MCS standard, the group master key identifier GMK-ID must then be determined by the receiving entity R. This is achieved by means of a step not shown implemented by the receiving entity R after receiving the frame T. In this step, included in a content transmission method according to the invention implemented by the transmitting entity E and by the receiving entity R and previously comprising the steps of method 1 according to the invention, the group master key identifier GMK-ID is determined by testing all the group master keys known to the receiving entity R. Indeed, the encryption mode specified by the technical specification TS 33.180 is AEAD-AES-128-GCM, which verifies the integrity, and it is therefore not possible for the receiving entity R to deceive of determined GMK group master key. All GMK group master keys associated with communication group G stored by receiving entity R or all GMK group master keys stored by receiving entity R can be tested.

[0051] The method 1 comprises, after the step 12 of selecting a security context S, a step 13 of encrypting the content C. The encryption 13 of the content C is carried out by the sending entity E according to the security context S selected in step 12. Indeed, the security context S determines whether end diversity must be used, in which case the encryption must be based on the group user key identifier GUK-ID and on the group master key identifier GMK-ID, or whether end diversity must not be used, in which case the encryption must not be based on the group user key identifier GUK-ID and must only be based on the group master key identifier GMK-ID.Encryption 13 is performed using a master key according to the SRTP (Secure Real Time Protocol) protocol in RFC3711 and according to the technical specification TS 33.180 point 7.5.1. The master key is obtained: . • If the security context is with endpoint diversity, from the group master key identifier GMK-ID and the group user key identifier GUK-ID, • If the security context is without end diversity, from the group master key identifier GMK-ID.

[0052] The method 1 comprises a step 14 of transmitting a frame T according to the SRTP protocol, such a frame T comprising the content C encrypted in step 13 and the security context S selected in step 12. The frame T is then transmitted to the receiving entity R, which uses the information included in the security context S and the information that it has at its disposal thanks to the topology and the context of the network to decrypt the content C.

Claims

Claims

1. Method (1) implemented by a transmitting client entity (E) included in a network according to the 3GPP MCS “3rd Generation Partnership Program Mission Critical Services” standard, the transmitting client entity (E) being configured to transmit content (C) intended for a receiving client entity (R) included in the network, the transmitting client entity (E) and the receiving client entity (R) being affiliated to the same communication group (G), the method (1) comprising at least one selection step (12), by the transmitting client entity (E) from at least one security context information (I) stored in the memory of the transmitting entity (E), of a security context (S) from among the following security contexts: - A security context (S) with end diversity,the security context (S) being formed of: • A long master key identifier (MKI) formed of a group master key identifier (GMK-ID) and a group user key identifier (GUK-ID), the group master key identifier (GMK-ID) being specific to the communication group (G), the group user key identifier (GUK-ID) being specific to a user of the issuing entity (E), or • A short master key identifier (MKI) formed of the group master key identifier (GMK-ID) or • A short master key identifier (MKI) formed of the group user key identifier (GUK-ID) or • No master key identifier (MKI). - A security context (S) without end diversity, the security context (S) being formed of: • A short master key identifier (MKI) formed of the group master key identifier (GMK-ID) or • No master key identifier (MKI).,

2. Method (1) according to the preceding claim further comprising the steps of: - Encryption (13) of the content (C), the content (C) being encrypted by the sending client entity (E), the encryption (13) of the content (C) being based on a master key according to the SRTP protocol "Secure Real Time Protocol", the master key being obtained: • If the security context (S) is with end diversity, from the group master key identifier (GMK-ID) and the group user key identifier (GUK-ID), • If the security context (S) is without end diversity, from the group master key identifier (GMK-ID), - Transmission (14) of a frame (T) to the receiving entity, according to the SRTP protocol, the frame (T) comprising the encrypted content (C) and the security context (S).

3. Method (1) according to any one of the preceding claims according to which the information (I) stored in the memory of the transmitting entity (E) is a set of parameters comprising the following parameters: - End diversity parameter (DE) comprising end diversity implementation information or not, - Parameter (TGMK) for transmission of the group master key identifier (GMK-ID) comprising information on transmission of the group master key identifier (GMK-ID) or not, - Parameter (TGUK) for transmission of the group user key identifier (GUK-ID) comprising information on transmission of the group user key identifier (GUK-ID) or not, and in that the security context (S) is constructed from the set of parameters.

4. Method (1) according to any one of the preceding claims wherein the communication group (G) is an MCPTT, MCVideo or MCData group.

5. Method (1) according to any one of the preceding claims according to which the security context information (I) is received (11) from a remote entity previously to the step (12) of selecting the security context (S).

6. Method (1) according to any one of the preceding claims according to which: - the group master key identifier (GMK-ID) can be obtained from the group user key identifier (GUK-ID) and an identity of the user of the issuing entity (E) and - the group user key identifier (GUK-ID) can be obtained from the group master key identifier (GMK-ID) and an identity of the user of the issuing entity (E).

7. Communication network according to the 3GPP MCS “3rd Generation Partnership Program Mission-Critical System” standard, the communication network comprising at least: - a transmitting client entity (E) configured to implement the method (1) according to any one of claims 1 to 6, - a receiving client entity (R) configured to receive the encrypted content (C) and the security context (S) transmitted by the transmitting entity (E).

Images