Method for changing the group key in a group of network elements in a network

The invention relates to a method for changing a group key in a group of network elements in a network system.

Background of the invention

Modern group-oriented and collaborative applications for data exchange between network elements of a group of network elements in a network system increasingly use the peer-to-peer principle. Compared to centralized approaches, this offers the advantage of greater independence from potentially expensive infrastructure, such as audio and video conferencing with H.32x systems, in the client-server configuration. Decentralized systems have proved to be more flexible here because there is no single point of failure <i>("Single Point of Failure")</i> gives and reduces dependence on an infrastructure. Decentralized solutions support in particular the spontaneous exchange of data and the mobility of the users of the network elements. This is advantageous, for example, for business communication via the Internet.

However, distributed configurations require mechanisms to ensure the confidentiality of the data being exchanged. In particular, this requires methods of exchanging keys used to encrypt / decrypt the exchanged data, the key exchange method having to ensure consistent renewal of the keys on all network elements involved in a group of network elements. While practicable solutions exist for centralist approaches, the development of efficient and secure distributed configuration procedures is the subject of intense research.

Secure data exchange within a group of network elements requires that only actively participating network elements have a current group or session key for encrypting / decrypting the exchanged data parts. In addition, with a changing group composition, i.e. the addition of another network element to the group or when a network element leaves the group, it may be desired and required that the content and subject matter of a consultation between users of the network elements be added to join or later rather leave the consultation, not become accessible. In the following, this more complex variant of a confidential consultation is considered. Variants with lower confidentiality requirements for a changing composition of the group of network elements can be derived therefrom.

Key management in such a group of network elements is subject to a number of different requirements. (1) Each network element of the group shall ensure that no one outside the group can gain access to the group key<i>("key authentication").</i> The prerequisite for this is a mutual authentication of each network element in the event of the addition of the network element to the group, which ensures that the added network element is also the network element expected of the group of network elements, and conversely, the network element or network element that is to be added. whose user gives the certainty that he can trust the group. (2) A network element leaving the session at any one time should not have access to a later-generated key for the exchange of data between the network elements in order to decrypt the further communication <i>("forward confidentiality").</i> (3) Network elements joining a meeting later shall not be granted access to a previously used key to disclose data that has been exchanged between the network elements of the group before accession. (4) None of the network elements leaving the group of network elements should be able to derive a currently used key by using older keys<i>("collusion freedom").</i>

Furthermore, it is desirable that compromise of a key does not result in coverage of prior keys <i>("perfect forward secrecy")</i> and that uncovering keys from previous sessions can not compromise the current key <i>("resistance to known key attacks").</i> It is almost obvious that there is a need for an efficient exchange protocol for the keys in order to minimize inter-key data exchange delays, especially for real-time applications such as audio and video conferencing, because in asynchronous Internet hosts are usually unable to Renew key synchronously.

In principle, two types of key exchange protocols are distinguished in groups of network elements, namely the key agreement protocols <i>(key agreement protocols)</i> and the key distribution protocols <i>("key distribution protocols").</i> The two types of protocol differ in the type of key renewal, that is, in terms of the method of replacing a previously used key with a new key for encrypting / decrypting the exchanged data.

Key agreement protocols are based on the Diffie-Hellman key exchange principle (cf. E. Rescorla: Diffie-Hellman Key Agreement Method. RFC 2631, June 1999). The basic principle is that each network element of the group of network elements must contribute to key generation. For this purpose, a network element is selected from the group of network elements, which generates an intermediate key, which is then distributed to the remaining members of the group of network elements. From the intermediate keys and their own contribution, the remaining network elements then generate a group key. Known examples of this type of key exchange protocols are CLIQUES (cf. <nplcit id="ncit0001" npl-type="s"><text>M. Steiner et al .: CLIQUES: A new approach to group key agreement. IEEE International Conference on Distributed Computing Systems, 1998, pp. 380-397</text></nplcit>) and TGDH (cf. <nplcit id="ncit0002" npl-type="b"><text>Y. Kim et al .: Simple and fault-tolerant key agreement for dynamic collaborative groups. In S. Jajodia (ed.): 7th ACM Conference on Computer and Communications Security, Athens, Greece, Nov. 2000, ACM Press, pp. 235-244</text></nplcit>). The latter is currently considered a very efficient key negotiation protocol.

In contrast, key distribution protocols dynamically determine one of the network elements which generates the new key and securely distributes it to the remaining network elements of the group. Most approaches use a key distribution tree. They differ in how the network elements of the group obtain the key through the key distribution tree. Examples of such key distribution protocols are DTKM (cf.<nplcit id="ncit0003" npl-type="s"><text>L. Dondeti et al .: Disec: A distributed framework for scalable secure many-to-many communication, Proceedings of The Fifth IEEE Symposium on Computers and Communications (ISCC 2000), July 2000</text></nplcit>) and one of Rodeh et al. proposed distribution tree (cf.<nplcit id="ncit0004" npl-type="s"><text>O. Rodeh et al .: Optimized Group Rekey for Group Communications Systems. In Symposium Network and Distributed System Security (NDSS), San Diego, California, Feb. 2000, pp. 39-48</text></nplcit>), which is an extension of a centralized logical key hierarchy (cf. <nplcit id="ncit0005" npl-type="s"><text>C. Wong et al .: Secure group communication using key graphs, IEEE / ACM Transaction on Networking 8 (1) 16-30, 2000</text></nplcit>).

Key distribution protocols are considered more efficient because they generally require less computational and communication overhead for generating and distributing the key.

Summary of the invention

The object of the invention is to provide a method for changing a group key in a group of network elements in a network system with a closed peer-to-peer configuration, in which an efficient and reliable generation and distribution of keys is ensured, which for encrypting / Decrypt the data exchanged in the group.

This object is achieved by a method according to independent claim 1. Advantageous embodiments of the invention are the subject of dependent subclaims.

According to the invention, a method for changing a group key <i>GK</i> for secure data exchange in a group of network elements <i>P₁</i> ... <i>P_n (n =</i> 2, 3, ...) in a network system having a closed peer-to-peer configuration and a virtual synchronity supporting group communication protocol in a communications layer of a system architecture of the network system, wherein upon a change in composition of the group of network elements <i>P₁</i> ... <i>P_n.</i> by adding a new network element <i>P_{n + 1}</i> to the group of network elements <i>P₁ ... P_n</i> added or by adding a network element <i>P_v</i> (1 <i>≤ v ≤ n</i>) the group of network elements <i>P₁ ... P_n</i> a group key renewal is performed, in which one of the group of network elements <i>P₁</i> ... <i>P_n</i> selected network element <i>P_i*</i> (1 <i>≤ i ≤ n)</i> a new group key <i>GK_New</i> generated and the new group key <i>GK_New</i> from the selected network element <i>P_i</i> to all other network elements <i>P_k</i> (1 ≤ <i>k</i> ≤ <i>n</i>+<i>1,</i> 1 ≤ <i>k</i> ≤ <i>n, k</i> ≠ <i>i, k</i> ≠ <i>v</i>) of the group of network elements <i>P₁</i> ... <i>P_n</i> in the modified composition is transmitted by the selected network element <i>P_i^*</i> with all other network elements <i>P_k</i> a key exchange according to the Diffie-Hellman principle for transmitting the new group key <i>GK_New</i> performs.

By means of the proposed method, when changing the composition of the group of network elements, a new group key for the encryption of data to be exchanged is generated in a secure and efficient manner and then distributed to the remaining members of the group of network elements. On the one hand, the method ensures a high safety standard by fulfilling the security requirements explained in the introduction, and on the other hand minimizes the computation effort in the case of group key renewal.

A preferred embodiment of the invention provides that in the group key renewal the selected network element <i>P *_i</i> is determined by using a token protocol a virtual token to a network element <i>P_i</i> (1 <i>≤ i ≤</i> n) from the group of network elements <i>P₁</i> ... <i>P_n</i> is awarded and so the network element <i>P_i</i> to a token holder <i>PT</i> becomes. Using a virtual token avoids explicit token passing and all related issues such as token loss and duplication.

An advantageous embodiment of the invention provides that in the group key renewal the selected network element <i>P_i*</i> is determined by using a token protocol a physical token to a network element <i>P_i</i> (1 ≤ <i>i</i> ≤ <i>n</i>) from the group of network elements <i>P₁</i> ... <i>P_n</i> is awarded and so the network element <i>P_i</i> to a token holder <i>PT</i> becomes.

In an expedient embodiment of the invention it is provided that the token assignment is carried out again for each further group key renewals, whereby the security standard is further increased.

An advantageous development of the invention provides that when using the virtual token of the token holder <i>PT</i> from the group of network elements <i>P₁</i> ... <i>P_n</i> is determined according to the following relationship <maths id="math0001" num=""><math display="block"><mi mathvariant="italic">PT</mi><mo>=</mo><mi mathvariant="italic">VK</mi>&lt;mtable /&gt;<mi>mod</mi><mspace width="1em" />&lt;mtable /&gt;<mi>n</mi><mo>.</mo></math><img file="EP1793525A1_D0001.tif" /></maths>in which <i>VK</i> a numeric value for a version number of the new group key generated during group key renewal <i>GK_New</i> and is incremented by 1 for each group key renewal.

In an expedient development of the invention it is provided that the group key renewal is carried out using the IKEv2 protocol (IKEv2 - "Internet Key Exchange Protocol"). This protects the identity of the network elements involved in the group. In addition, the volume of data exchange is minimized.

In a preferred embodiment of the invention can be provided that the addition of the new network element <i>P_{n + 1}</i> to the group of network elements <i>P₁</i> ... <i>P_n</i> the new group key <i>GK_New</i> is transmitted in the key exchange according to the Diffie-Hellman principle by means of a message of the following structure: <maths id="math0002" num=""><math display="block"><msub><mi>M</mi><mrow><mi>j</mi><mo>⁢</mo><mn>5</mn></mrow></msub><mo>⁢</mo><mfenced separators=""><msub><mi>P</mi><mi>i</mi></msub><mo>→</mo><msub><mi>P</mi><mn mathvariant="italic">1</mn></msub><mo>.</mo><msub><mi>P</mi><mn mathvariant="italic">2</mn></msub><mo>...</mo><msub><mi>P</mi><mrow><mi>n</mi><mo>+</mo><mn mathvariant="italic">1</mn></mrow></msub></mfenced><mo>:</mo><mi mathvariant="italic">HDR</mi><mo mathvariant="italic">.</mo><msub><mi mathvariant="italic">GK</mi><mi mathvariant="italic">old</mi></msub><mfenced open="{" close="}" separators=""><msub><mi mathvariant="italic">ID</mi><mrow><mi mathvariant="normal">i</mi><mo>.</mo></mrow></msub><mo>⁢</mo><msub><mi>N</mi><mi>i</mi></msub></mfenced><mo>.</mo><msub><mi>K</mi><mrow><mi>i</mi><mo>⁢</mo><mn mathvariant="italic">1</mn></mrow></msub><mfenced open="{" close="}" separators=""><msub><mi mathvariant="italic">VK</mi><mi mathvariant="italic">old</mi></msub><mo>⁢</mo><msub><mi mathvariant="italic">GK</mi><mi mathvariant="italic">New</mi></msub></mfenced><mo>.</mo><mo>...</mo><mo>.</mo><msub><mi mathvariant="italic">K</mi><mi mathvariant="italic">in</mi></msub><mfenced open="{" close="}" separators=""><msub><mi mathvariant="italic">VK</mi><mi mathvariant="italic">old</mi></msub><mo>⁢</mo><msub><mi mathvariant="italic">GK</mi><mi mathvariant="italic">New</mi></msub></mfenced><mo>.</mo><mi mathvariant="italic">SK</mi><mfenced open="{" close="}" separators=""><msub><mi mathvariant="italic">GK</mi><mi mathvariant="italic">New</mi></msub><mo>⁢</mo><msub><mi mathvariant="italic">VK</mi><mi mathvariant="italic">New</mi></msub><mo>⁢</mo><mi mathvariant="italic">GSA</mi><mo>⁢</mo><msub><mi mathvariant="italic">ID</mi><mi mathvariant="italic">i</mi></msub></mfenced><mo>.</mo><msub><mi mathvariant="italic">GK</mi><mi mathvariant="italic">New</mi></msub><mfenced open="{" close="}" separators=""><msup><mi>G</mi><mrow><mi mathvariant="italic">rn</mi><mo>+</mo><mn>1</mn></mrow></msup><mo>⁢</mo><msub><mi mathvariant="italic">ID</mi><mrow><mi>n</mi><mo>+</mo><mn mathvariant="italic">1</mn></mrow></msub></mfenced></math><img file="EP1793525A1_D0002.tif" /></maths>wherein a first message part <i>GK_old {ID_i, N_i)</i> which with an old group key used before the new group key <i>GK_old</i> is encrypted, an identity <i>ID_i</i> of the token holder <i>PT</i> and a random number N includes; wherein a second message part <i>K_il {VK_old, GK_New},</i> ..., <i>K_in {VK_old, GK_New}</i> the new group key <i>GK_New</i> and a numerical value for the version number <i>VK_old</i> of the old group key <i>GK_old</i> comprises; a third message part <i>SK {GC_New, UK_New, GSA, ID_i},</i> which with a session key <i>SK</i> is encrypted, the new group key <i>GK_New.</i> a numerical value for the version number <i>VK_New</i> of the new group key <i>GK_New.</i> a security association <i>GSA</i> the group of network elements <i>P₁ ... P_n</i> as well as the identity <i>ID_i</i> of the token holder <i>PT</i> to that to the group of network elements <i>P₁</i> ... <i>P_n</i> added, new network element <i>P_{n + 1}</i> transmitted; and a fourth message part <i>GK_New (G^{rn + 1}, ID_{n + 1}},</i> which with the new group key <i>GK_New</i> is encrypted, an identity <i>ID_{n + 1}</i> and a public Diffie-Hellman value <i>G^{rn + 1}</i> to the group of network elements <i>P₁ ... P_n</i> added, new network element <i>P_{n + 1}</i> umfaßt.Netzelementes <i>P_{n + 1}</i> includes.

In order to improve the confidentiality among the users of the network elements, an advantageous embodiment of the invention provides that upon the addition of the new network element <i>P_{n + 1}</i> to the group of network elements <i>P₁</i> ... <i>P_n</i> authentication of the new network element before the group key renewal <i>P_{n + 1}</i> is carried out. The authentication of the new network element<i>P_{n + 1}</i> is preferred by the selected network element <i>P_i^*</i> executed. Appropriately, in one embodiment of the invention, the authentication of the new network element<i>P_{n + 1}</i> executed by digital signature.

Preferably, an embodiment of the invention provides that upon successful authentication, the selected network element <i>P_i^*</i> for all other network elements <i>P_k</i> the group of network elements <i>P₁</i> ... <i>P_n</i> a respective public Diffie-Hellman value <i>Gⁱ</i> (1 ≤ <i>i ≤ n</i>) to the new network element <i>P_{n + 1}</i> passes and that the new network element <i>P_{n + 1}</i> his public Diffie-Hellman value <i>G^{n + 1}</i> to the selected network element <i>P_i*</i> which in turn gives the public Diffie-Hellman value <i>G^{n + 1}</i> of the new network element <i>P_{n + 1}</i> to all other network elements <i>P_k</i> the group of network elements <i>P₁</i> ... <i>P_n</i> passes.

In an advantageous embodiment of the invention, it is provided that the authentication of the new network element <i>P_{n + 1}</i> using the IKEv2 protocol.

A preferred embodiment of the invention can provide that in the authentication of the new network element <i>P_{n + 1}</i> through the selected network element <i>P_i*</i> the following messages between the new network element <i>P_{n + 1}</i> and the selected network element <i>P_i*</i> be replaced: <maths id="math0003" num=""><math display="block"><msub><mi mathvariant="italic">M</mi><mrow><mi mathvariant="italic">j</mi><mo>⁢</mo><mn mathvariant="italic">1</mn></mrow></msub><mo>⁢</mo><mfenced separators=""><msub><mi mathvariant="italic">P</mi><mi mathvariant="italic">i</mi></msub><mo mathvariant="italic">→</mo><msub><mi mathvariant="italic">P</mi><mrow><mi mathvariant="italic">n</mi><mo mathvariant="italic">+</mo><mn mathvariant="italic">1</mn></mrow></msub></mfenced><mo mathvariant="italic">:</mo><mi mathvariant="italic">HDR</mi><mo mathvariant="italic">.</mo><msup><mi mathvariant="italic">a</mi><mi mathvariant="italic">ri</mi></msup><mo mathvariant="italic">.</mo><msub><mi mathvariant="italic">SA</mi><mi mathvariant="italic">i</mi></msub><mo mathvariant="italic">.</mo><msub><mi mathvariant="italic">N / A</mi><mi mathvariant="italic">i</mi></msub></math><img file="EP1793525A1_D0003.tif" /></maths><maths id="math0004" num=""><math display="block"><msub><mi mathvariant="italic">M</mi><mrow><mi mathvariant="italic">j</mi><mo>⁢</mo><mn mathvariant="italic">2</mn></mrow></msub><mo>⁢</mo><mfenced separators=""><msub><mi mathvariant="italic">P</mi><mrow><mi mathvariant="italic">n</mi><mo mathvariant="italic">+</mo><mn mathvariant="italic">1</mn></mrow></msub><mo>→</mo><msub><mi mathvariant="italic">P</mi><mi mathvariant="italic">i</mi></msub></mfenced><mo mathvariant="italic">:</mo><mi mathvariant="italic">HDR</mi><mo mathvariant="italic">.</mo><msup><mi mathvariant="italic">a</mi><mrow><mi mathvariant="italic">rn</mi><mo mathvariant="italic">+</mo><mn mathvariant="italic">1</mn></mrow></msup><mo mathvariant="italic">.</mo><msub><mi mathvariant="italic">SA</mi><mrow><mi>n</mi><mo>+</mo><mn mathvariant="italic">1</mn></mrow></msub><mo mathvariant="italic">.</mo><msub><mi mathvariant="italic">N / A</mi><mrow><mi>n</mi><mo>+</mo><mn mathvariant="italic">1</mn></mrow></msub></math><img file="EP1793525A1_D0004.tif" /></maths><maths id="math0005" num=""><math display="block"><msub><mi mathvariant="italic">M</mi><mrow><mi mathvariant="italic">J</mi><mo>⁢</mo><mn>3</mn></mrow></msub><mo>⁢</mo><mfenced separators=""><msub><mi mathvariant="italic">P</mi><mi mathvariant="italic">i</mi></msub><mo>→</mo><msub><mi mathvariant="italic">P</mi><mrow><mi mathvariant="italic">n</mi><mo mathvariant="italic">+</mo><mn mathvariant="italic">1</mn></mrow></msub></mfenced><mo mathvariant="italic">:</mo><mi mathvariant="italic">HDR</mi><mo mathvariant="italic">.</mo><mi mathvariant="italic">SK</mi><mfenced open="{" close="}" separators=""><msub><mi mathvariant="italic">ID</mi><mi>i</mi></msub><mo>.</mo><msub><mi mathvariant="italic">CERT</mi><mi>i</mi></msub><mo>.</mo><msub><mi mathvariant="italic">ID</mi><mn mathvariant="italic">1</mn></msub><mo>.</mo><msub><mi mathvariant="italic">ID</mi><mn>2</mn></msub><mo>...</mo><msub><mi mathvariant="italic">ID</mi><mi>n</mi></msub><mo>.</mo><msup><mi>G</mi><mrow><mi>r</mi><mo>⁢</mo><mn mathvariant="italic">1</mn></mrow></msup><mo>.</mo><msup><mi>G</mi><mrow><mi mathvariant="italic">r</mi><mo>⁢</mo><mn mathvariant="italic">2</mn></mrow></msup><mo>...</mo><msup><mi>G</mi><mi mathvariant="italic">rn</mi></msup></mfenced></math><img file="EP1793525A1_D0005.tif" /></maths><maths id="math0006" num=""><math display="block"><msub><mi mathvariant="italic">M</mi><mrow><mi mathvariant="italic">J</mi><mo>⁢</mo><mn mathvariant="italic">4</mn></mrow></msub><mo>⁢</mo><mfenced separators=""><msub><mi mathvariant="italic">P</mi><mrow><mi mathvariant="italic">n</mi><mo mathvariant="italic">+</mo><mn mathvariant="italic">1</mn></mrow></msub><mo>→</mo><msub><mi mathvariant="italic">P</mi><mi mathvariant="italic">i</mi></msub></mfenced><mo mathvariant="italic">:</mo><mi mathvariant="italic">HDR</mi><mo mathvariant="italic">.</mo><mo>-</mo><mi mathvariant="italic">SK</mi><mfenced open="{" close="}" separators=""><msub><mi mathvariant="italic">ID</mi><mrow><mi>n</mi><mo>+</mo><mn mathvariant="italic">1</mn></mrow></msub><mo>⁢</mo><msub><mi mathvariant="italic">CERT</mi><mrow><mi>n</mi><mo>+</mo><mn mathvariant="italic">1</mn></mrow></msub><mo>⁢</mo><msub><mi mathvariant="italic">SIG</mi><mrow><mi>n</mi><mo>+</mo><mn mathvariant="italic">1</mn></mrow></msub><mo>⁢</mo><msup><mi>G</mi><mrow><mi mathvariant="italic">rn</mi><mo>+</mo><mn mathvariant="italic">1</mn></mrow></msup></mfenced></math><img file="EP1793525A1_D0006.tif" /></maths>in which <i>HDR</i> Header data, <i>CERT</i> a certificate of a public RSA key, <i>SIG</i> the digital signature, <i>G^r</i> a public Diffie-Hellman value for generating a temporary secure transmission channel <i>K</i> and <i>a^r</i> a public value for generating a session key <i>SK</i> are; in which <i>SK</i>{M} an encryption of the message M using an encryption key <i>SK_e</i> and authentication using an authentication key <i>SK_a</i> Show; and being with the news <i>M_J1</i> and <i>M_J2</i> a security association SA is negotiated.

Appropriately provides a development of the invention that when leaving a network element <i>P_v</i> the group of network elements <i>P₁</i> ... <i>P_n</i> a group key renewal analogous to the addition of the new network element <i>P_{n + 1}</i> is carried out.

In a preferred embodiment of the invention, it is provided that when leaving the network element <i>P_v</i> all other network elements <i>P_x</i> (1 ≤ <i>x ≤ n, x</i> ≠ <i>v</i>) of the group of network elements <i>P₁ ... P_n</i> each in the changed composition a public Diffie-Hellman value <i>G^v</i> of the group of network elements <i>P₁</i> ... <i>P_n</i> leaving network element <i>P_v</i> Clear.

An embodiment of the invention provides that the new group key <i>GK_New</i> in a data communication between the plurality of network elements <i>P_i</i> in the network system for exchanging video and / or audio and / or text data.

Description of preferred embodiments of the invention

The invention is explained below with reference to embodiments with reference to a drawing. Hereby show:<dl id="dl0001" compact="compact"><dt>Fig. 1</dt><dd>a schematic representation of a system architecture of a network system;</dd><dt>Fig. 2</dt><dd>a schematic representation for explaining a method in the context of a key renewal;</dd><dt>Fig. 3</dt><dd>a schematic representation for explaining an addition of a new network element to a group of network elements;</dd><dt>Fig. 4</dt><dd>a schematic representation for explaining a procedure when a network element leaves the group of network elements;</dd><dt>Fig. 5</dt><dd>a graphical representation for comparing the delay in the key renewal depending on the size of the group of network elements for different methods; and</dd><dt>Fig. 6</dt><dd>a graph for comparing key renewal delay for various methods when a network element leaves the group of network elements.</dd></dl>

The following is a method of changing a group key in a group of network elements <i>P₁ ... P_n</i> (<i>n</i> = 2, 3, ...) in a network system with a closed peer-to-peer configuration with reference to Figs. 1 to 6 explained. Here, a distribution method in connection with the renewal and the subsequent distribution of a key for encrypting / decrypting the data exchanged in the group is explained in particular. For simplicity's sake, the key distribution method will be partly abbreviated VTKD<i>("virtual token based key distribution")</i> designated. In an alternative embodiment, a physical token is used, which is why the abbreviation TKD<i>("token based key distribution")</i> is usable.

Fig. 1 shows a schematic representation of a system architecture, which is based on the following description. The three-layer architecture comprises an application layer 1, a security layer 2 and a communication layer 3. A key distribution protocol 4 is assigned to the security layer 2 and runs in a signaling part. With the help of a group key both media data and signaling data can be encrypted.

The application layer 1 comprises components required for a particular application. In a videoconferencing application, these are in particular QoS management (QoS management).<i>"Quality of service</i> "), a floor control, an audio manager 6, a video manager 5 and a whiteboard 4. An essential component is a group management 8, which is assumed below to also be integrated in the application layer 1. The group management 8 receives requests for accessing or leaving the group of network elements via a user interface, which are forwarded by the user interface via a group communication protocol 9 to the network elements of the group. The failure of a network element from the group of network elements is detected by means of the group communication protocol 9 and the other network elements brought to the knowledge.

The security layer 2 comprises encryption modules 10, an authentication module 11 and the key distribution protocol 4, which will be described in detail below. A key renewal is triggered when the composition of the group of network elements changes, that is, a new network element joins the group<i>( "Join")</i> a network element leaves the group of network elements <i>( "Leave")</i> or a network element fails. The addition to the group of network elements in VTKD involves mutual authentication between the new network element and the adjoining network element to ensure that both sides can trust each other.

The communication layer 3 comprises protocols for transmission of signaling and media data. For key renewal, only the group communication protocol 9 is relevant, which forms an important basis. In collaborative peer-to-peer applications, the group communication protocol provides the foundation for reliable operation of the system or application. It must update group data in all peers and ensure that all peers have a consistent view of the group so that they can make timely decisions on QoS parameter settings, floor assignment, and group key renewal. For this, the group communication protocol 9 must secure a virtual synchronization between the group members. Virtual synchronization means that all group members receive the exchanged messages reliably in the order in which they were sent. This requires that the group communication protocol 9 be reliable, ordered, and atomic to avoid data loss, secure a transmission order, and ensure consistent update of the group data. Virtual synchronization requires that the group communication protocol 9 display all changes in group composition, such as joining, leaving or failing, to all members. There are protocols known that support virtual synchronization like RMP (cf. <nplcit id="ncit0006" npl-type="s"><text>B. Whetten et al .: A High Performance Totally Ordered Multicast Protocol. In Theory and Practice in Distributed Systems, International Workshop, Lecture Notes in Computer Science 938, September 1994, pp. 33-57</text></nplcit>), the totem protocol (cf. <nplcit id="ncit0007" npl-type="b"><text>DA Agarwal: Totem: A Reliable Ordered Delivery Protocol for Interconnected Local Area Network, Ph.D thesis, University of Santa Barbara, December 1994</text></nplcit>) and GCP (cf. <nplcit id="ncit0008" npl-type="b"><text>EC Popovici et al.: Consistency Support for Decentralized Management in Closed Multiparty Conferences Using SIP, Proc. of the 11th IEEE International Conference on Networks (ICON 2003), Sydney, Australia, IEEE Press, 2003, pp. 295-300</text></nplcit>; <nplcit id="ncit0009" npl-type="s"><text>Zuehlke, M. et al .: A Signaling Protocol for Small Closed Dynamic Multi-peer Groups, in Z. Mammeri et al. (eds.): High Speed ​​Networks and Multimedia Communications (HSNMC 2004), Springer publishing house, Berlin, Heidelberg 2004, S. 973-984</text></nplcit>).

Distributed key management requires virtual synchronization on the used group communication protocol 9, that is, there is a close relationship between these two protocols. If this property is not met, the different view of the group of network elements may lead to key renewal confusion because it may determine multiple network elements of the group for key renewal. Therefore, it is assumed below that the property of virtual synchronization for the group communication protocol 9 is given.

In the method proposed here for the secure exchange of data in the closed peer-to-peer configuration, the key exchange during a key renewal is based on the Diffie-Hellman (DH) principle (cf. <nplcit id="ncit0010" npl-type="s"><text>E. Rescorla: Diffie-Hellman Key Agreement Method. RFC 2631, June 1999</text></nplcit>), so there is no central key management. In contrast to the key exchange between two network elements of the group, in the distributed approach each network element of the group with each other network element calculates a secret key according to the Diffie-Hellman principle. This secret key is referred to herein as a common or two-sided DH secret.

The two-sided DH secrets are stored among the members of the group of network elements and then used for distribution of the group key. As regards the members of the group of network elements, it is assumed that they have the same rights and the same confidence in them. This means that each network element of the group of network elements is allowed to authenticate a new network element and renew the group key. It is further believed that a new network element that joins the group of network elements is trusted and does not actively attempt to interfere with the ongoing data exchange or pass the session key to network elements that are not members of the group. However, no assumptions are made about the trustworthiness of the network elements after leaving the group of network elements. These assumptions are in accordance with the practice and are usually taken.

VTKD uses a token protocol. Only one token holder has the right to renew the group key and to authenticate a new network element to be added. However, VTKD does not use a physical token passed on a logical circle of the network elements of the group, but a virtual token. Virtual in this context means that the position of the virtual token and thus of the token holder is recalculated for each key distribution. This avoids explicit token passing, with all associated issues such as token loss and duplication. The new token position <i>PT</i> is calculated as follows: <maths id="math0007" num="(1)"><math display="block"><mi mathvariant="italic">PT</mi><mo>=</mo><mi mathvariant="italic">VK</mi>&lt;mtable /&gt;<mi>mod</mi><mspace width="1em" />&lt;mtable /&gt;<mi>n</mi><mn>,</mn></math><img file="EP1793525A1_D0007.tif" /></maths>in which <i>VK</i> a numeric value for a respective version number of the group key and <i>n</i> the current number of network elements of the group of network elements <i>P₁</i> ... <i>P_n</i> is. <i>VK</i> is incremented by 1 each time the group key is updated. The value for the version number is also used in the log to avoid replay attacks, which is explained in more detail below.

Ensuring virtual synchronization by means of the group communication protocol ensures that each network element of the group of network elements knows an actual group size and the key version. In this way, each member of the group of network elements can uniquely determine the position of the virtual token.

Changing the composition of the group of network elements triggers a key renewal procedure. The token holder generates a new key and starts distributing it to the rest of the group of network elements. To do this, the token holder builds temporary, separate transmission channels to each member of the group of network elements using the respective DH shared shared secret.

Fig. 2 shows a schematic representation for a group of four network elements <i>P₁, P₂, P₃, P₄.</i> in which <i>P₁</i> the current token holder is. Each member of the group of network elements knows its DH secret with each other of the network elements. How to save<i>P₁</i> the DH secret Rils <i>G^r1r2, g^R1R3</i> and <i>G^r1r4, P₂</i> saves the DH secrets <i>G^r2r1, g^R2R3</i> and <i>G^r2r4, P</i>₁ then builds using the common DH secrets <i>G^r1r2, g^R1R3, g^r1r4</i> secret channels <i>K₁₂, K₁₃, K₁₄</i> to <i>P₂, P₃</i> and <i>P₄</i> over which the new group key will be distributed. The separate secret transmission channels are by means of a secret key<i>K_ij</i> defined between the two network elements of the <i>P_i, P_j</i> is calculated. The following calculation scheme is used:<maths id="math0008" num="(2)"><math display="block"><msub><mi>K</mi><mrow><mi mathvariant="italic">ij</mi><mo>-</mo><mi>e</mi></mrow></msub><mo>=</mo><mi>H</mi><mfenced separators=""><msup><mi>G</mi><mi mathvariant="italic">Riji</mi></msup><mo>.</mo><msup><mi>G</mi><mi mathvariant="italic">rirj</mi></msup><mrow><mo>|</mo><msub><mi>N</mi><mi>i</mi></msub><mo>|</mo><msub><mi mathvariant="italic">ID</mi><mi>i</mi></msub><mfenced open="|" close="|"><msub><mi mathvariant="italic">ID</mi><mi>j</mi></msub></mfenced><mo>⁢</mo><mn>0</mn></mrow></mfenced></math><img file="EP1793525A1_D0008.tif" /></maths><maths id="math0009" num="(3)"><math display="block"><mtable><mtr><mtd><msub><mi>K</mi><mrow><mi mathvariant="italic">ij</mi><mo>-</mo><mi>a</mi></mrow></msub><mo>=</mo><mi>H</mi><mfenced separators=""><msup><mi>G</mi><mi mathvariant="italic">Riji</mi></msup><mo>.</mo><msup><mi>G</mi><mi mathvariant="italic">rirj</mi></msup><mrow><mo>|</mo><msub><mi>N</mi><mi>i</mi></msub><mo>|</mo><msub><mi mathvariant="italic">ID</mi><mi>i</mi></msub><mfenced open="|" close="|"><msub><mi mathvariant="italic">ID</mi><mi>j</mi></msub></mfenced><mo>⁢</mo><mn>1</mn></mrow></mfenced></mtd><mtd><mfenced separators=""><mi>j</mi><mo>=</mo><mn>1</mn><mo>.</mo><mn>2</mn><mo>.</mo><mo>...</mo><mi>n</mi><mtable /><mi>and</mi><mtable /><mi>j</mi><mo>≠</mo><mi>i</mi></mfenced></mtd></mtr></mtable></math><img file="EP1793525A1_D0009.tif" /></maths>

A key pair is calculated. <i>K_ij-e</i> is used for encrypting a message while <i>K_ij-a</i> to check the authenticity of the messages. The key is generated using a cryptographic hash function<i>H (k, M),</i> in which <i>k</i> a key and M denote the message. Preference is given to HMAC (cf.<nplcit id="ncit0011" npl-type="s"><text>H. Krawczyk et al .: HMAC: Keyed Hashing for Message Authentication, RFC 2104, February 1997</text></nplcit>) used. In the calculation go the common DH secret between the token holder and the network element of the group, their identities<i>ID</i> and a random number N, which the token holder sends to the network element, which will be explained in more detail below. The symbol "|" denotes a chain.

Each member of the group of network elements each has the common DH secrets with the other members of the group of network elements corresponding to the current group composition. This is ensured by the fact that remaining network elements delete a respective DH secret in their table when a network element leaves the group of network elements. In the case of the addition of a new network element to the group of network elements, during the authentication phase, the token holder sends all public DH values ​​of the network elements of the group of network elements to the new network element. Conversely, the new network element passes its public DH value to the token holder, which then forwards it to the other members of the group of network elements. Each member of the group of network elements then computes the common DH secret with the new network element. In this way, the new network element will also be able to perform the key renewal and distribution if it is assigned the virtual token.

<u style="single">Joining a new network element (join procedure)</u>

The addition to the group of network elements involves two steps: (i) authentication and (ii) a renewal of a session key required due to the change in the composition of the group of network elements.

Fig. 3 shows a schematic representation of the process of the addition of a new network element. Five messages or communication rounds are needed, four for authentication and one for key renewal.

For mutual authentication between the token holder and the added new network element, any protocol may be used for instance authentication, such as the X.509 authentication procedure (see ITU-T Recommendation X.509 ISO / IEC 9594-8: Public Key and Attribute Certificate Frameworks), IKE (cf. <nplcit id="ncit0012" npl-type="s"><text>D. Harkins et al .: The Internet Key Exchange (IKE), RFC2409, Nov. 1998</text></nplcit>) or JFK (cf. <nplcit id="ncit0013" npl-type="s"><text>W. Aliel et al .: Just Fast Keying (JFK). draft-ietf-ipsec-jfk-04.txt. July 2002</text></nplcit>). In the following embodiment, IKEv2 ("Internet Key Exchange Protocol") (cf.<nplcit id="ncit0014" npl-type="s"><text>C. Kaufman: Internet Key Exchange (IKEv2) Protocol, draft-ietf-ipsec-ikev2-07.txt, April 2003</text></nplcit>) which, unlike most other protocols, protects the identity of the network elements involved in authentication and requires fewer communications rounds / messages. IKEv2 is used here as a starting point and adapted for the proposed method.

IKEv2 supports two forms of authentication. Digital signatures and pre-agreed common secrets. The following uses digital signatures that are better suited for peer-to-peer configurations than shared secrets that support client / server architectures.

For digital signatures, successful authentication depends on the authenticity of a public key. This is mostly checked by using certificates. For example, the X.509 certificate (cf. R. Housley et al .: Internet X.509 Public Key Infrastructure Certificate and CRL Profiles. RFC 2459, January 1999) are currently widely used. It recommends the use of an RSA signature. For this, both partners must be in possession of an RSA key pair. Of course, the public key of a certified authority is necessary for both partners to verify the certificates signed by the certified authority.

Fig. 3 shows the accession of a new partner <i>P_{n + 1}</i> to one out <i>n</i> Participants existing group of network elements <i>P₁</i> ... <i>P_n,</i> It is assumed that the network element <i>P_i</i> is the current token holder, which was determined according to formula (1). For mutual authentication between<i>P_i</i> and <i>P_{n + 1}</i> the following four messages are exchanged, where <i>HDR</i> the message button denotes: <maths id="math0010" num=""><math display="block"><msub><mi mathvariant="italic">M</mi><mrow><mi mathvariant="italic">j</mi><mo>⁢</mo><mn mathvariant="italic">1</mn></mrow></msub><mo>⁢</mo><mfenced separators=""><msub><mi mathvariant="italic">P</mi><mi mathvariant="italic">i</mi></msub><mo mathvariant="italic">→</mo><msub><mi mathvariant="italic">P</mi><mrow><mi mathvariant="italic">n</mi><mo mathvariant="italic">+</mo><mn mathvariant="italic">1</mn></mrow></msub></mfenced><mo mathvariant="italic">:</mo><mi mathvariant="italic">HDR</mi><mo mathvariant="italic">.</mo><msup><mi mathvariant="italic">a</mi><mi mathvariant="italic">ri</mi></msup><mo mathvariant="italic">.</mo><msub><mi mathvariant="italic">SA</mi><mi mathvariant="italic">i</mi></msub><mo mathvariant="italic">.</mo><msub><mi mathvariant="italic">N / A</mi><mi mathvariant="italic">i</mi></msub></math><img file="EP1793525A1_D0010.tif" /></maths><maths id="math0011" num=""><math display="block"><msub><mi mathvariant="italic">M</mi><mrow><mi mathvariant="italic">j</mi><mo>⁢</mo><mn mathvariant="italic">2</mn></mrow></msub><mo>⁢</mo><mfenced separators=""><msub><mi mathvariant="italic">P</mi><mrow><mi mathvariant="italic">n</mi><mo mathvariant="italic">+</mo><mn mathvariant="italic">1</mn></mrow></msub><mo>→</mo><msub><mi mathvariant="italic">P</mi><mi mathvariant="italic">i</mi></msub></mfenced><mo mathvariant="italic">:</mo><mi mathvariant="italic">HDR</mi><mo mathvariant="italic">.</mo><msup><mi mathvariant="italic">a</mi><mrow><mi mathvariant="italic">rn</mi><mo mathvariant="italic">+</mo><mn mathvariant="italic">1</mn></mrow></msup><mo mathvariant="italic">.</mo><msub><mi mathvariant="italic">SA</mi><mrow><mi>n</mi><mo>+</mo><mn mathvariant="italic">1</mn></mrow></msub><mo mathvariant="italic">.</mo><msub><mi mathvariant="italic">N / A</mi><mrow><mi>n</mi><mo>+</mo><mn mathvariant="italic">1</mn></mrow></msub></math><img file="EP1793525A1_D0011.tif" /></maths><maths id="math0012" num=""><math display="block"><msub><mi mathvariant="italic">M</mi><mrow><mi mathvariant="italic">J</mi><mo>⁢</mo><mn>3</mn></mrow></msub><mo>⁢</mo><mfenced separators=""><msub><mi mathvariant="italic">P</mi><mi mathvariant="italic">i</mi></msub><mo>→</mo><msub><mi mathvariant="italic">P</mi><mrow><mi mathvariant="italic">n</mi><mo mathvariant="italic">+</mo><mn mathvariant="italic">1</mn></mrow></msub></mfenced><mo mathvariant="italic">:</mo><mi mathvariant="italic">HDR</mi><mo mathvariant="italic">.</mo><mi mathvariant="italic">SK</mi><mfenced open="{" close="}" separators=""><msub><mi mathvariant="italic">ID</mi><mi>i</mi></msub><mo>.</mo><msub><mi mathvariant="italic">CERT</mi><mi>i</mi></msub><mo>.</mo><msub><mi mathvariant="italic">ID</mi><mn mathvariant="italic">1</mn></msub><mo>.</mo><msub><mi mathvariant="italic">ID</mi><mn>2</mn></msub><mo>...</mo><msub><mi mathvariant="italic">ID</mi><mi>n</mi></msub><mo>.</mo><msup><mi>G</mi><mrow><mi>r</mi><mo>⁢</mo><mn mathvariant="italic">1</mn></mrow></msup><mo>.</mo><msup><mi>G</mi><mrow><mi mathvariant="italic">r</mi><mo>⁢</mo><mn mathvariant="italic">2</mn></mrow></msup><mo>...</mo><msup><mi>G</mi><mi mathvariant="italic">rn</mi></msup></mfenced></math><img file="EP1793525A1_D0012.tif" /></maths><maths id="math0013" num=""><math display="block"><msub><mi mathvariant="italic">M</mi><mrow><mi mathvariant="italic">J</mi><mo>⁢</mo><mn mathvariant="italic">4</mn></mrow></msub><mo>⁢</mo><mfenced separators=""><msub><mi mathvariant="italic">P</mi><mrow><mi mathvariant="italic">n</mi><mo mathvariant="italic">+</mo><mn mathvariant="italic">1</mn></mrow></msub><mo>→</mo><msub><mi mathvariant="italic">P</mi><mi mathvariant="italic">i</mi></msub></mfenced><mo mathvariant="italic">:</mo><mi mathvariant="italic">HDR</mi><mo mathvariant="italic">.</mo><mo>-</mo><mi mathvariant="italic">SK</mi><mfenced open="{" close="}" separators=""><msub><mi mathvariant="italic">ID</mi><mrow><mi>n</mi><mo>+</mo><mn mathvariant="italic">1</mn></mrow></msub><mo>⁢</mo><msub><mi mathvariant="italic">CERT</mi><mrow><mi>n</mi><mo>+</mo><mn mathvariant="italic">1</mn></mrow></msub><mo>⁢</mo><msub><mi mathvariant="italic">SIG</mi><mrow><mi>n</mi><mo>+</mo><mn mathvariant="italic">1</mn></mrow></msub><mo>⁢</mo><msup><mi>G</mi><mrow><mi mathvariant="italic">rn</mi><mo>+</mo><mn mathvariant="italic">1</mn></mrow></msup></mfenced></math><img file="EP1793525A1_D0013.tif" /></maths>

Mean here <i>CERT</i> the certificate of public RSA key and <i>SIG</i> the digital signature. SK {M} means that the message M is under a distribution key<i>SK_e</i> encrypted and under an authentication key <i>SK_a</i> is authenticated. <i>G^r</i> is the public DH value for generating the temporary secure channel K. <i>a^r</i> is the public DH value for generating a session key <i>SK</i>, Like the digital signature<i>SIG</i> and the session key <i>SK</i> is generated in detail in the standard IKEv2 (cf. <nplcit id="ncit0015" npl-type="s"><text>C. Kaufman: Internet Key Exchange (IKEv2) Protocol, draft-ietf ipsec-ikev2-07.txt, April 2003</text></nplcit>) and therefore requires no further execution here.

The news <i>M_j1</i> and <i>M_j2</i> fulfill two functions. They serve on the one hand to negotiate a security association SA. The security association<i>SA</i> specifies cryptographic parameters in the messages <i>M_j3</i> and <i>M_j4</i> be used. Further, with the news<i>M_j1</i> and <i>M_j2</i> the public DH values ​​a^r and the random numbers <i>N / A</i> exchanged between both partners. These are used to generate the session key<i>SK</i> used to protect the following messages <i>M_j3</i> and <i>M_j4</i> is used.

The news <i>M_j3</i> and <i>M_j4</i> serve the mutual authentication of the partners and the negotiation of the security associations, which is used for the further communication between the two partners. The authentication of the partners takes place by means of mutual verification of the signatures<i>SIG</i>, For this purpose, both peers sign the concatenation of their first messages with the random number of the partner with their private RSA key. This eliminates possible man-in-the-middle attacks because the attacker can not change the signatures without knowing the private RSA keys of both partners.

The principle of negotiation of the security association can not be applied unchanged to the procedure proposed here, as IKEv2 is a two-way relationship. <i>M_j3</i> and <i>M_j4</i> additionally exchange group information in VTKD. The message<i>M_j3</i> transports the identities of all group members <i>(ID₁, ID₂.</i> ..., <i>ID₁₁)</i> and their associated public DH values ​​(<i>G</i>^r1. <i>G</i>^r2, ..., <i>G</i>^rn). The invited partner announces<i>M_j4</i> his identity <i>ID_{n + 1}</i> and its public DH value <i>G</i>^{rn + 1} back.

If the authentication is unsuccessful, the token holder informs with the message <i>M_jf</i>: <maths id="math0014" num=""><math display="block"><msub><mi mathvariant="italic">M</mi><mi mathvariant="italic">jf</mi></msub><mfenced separators=""><msub><mi mathvariant="italic">P</mi><mi mathvariant="normal">i</mi></msub><mo mathvariant="italic">→</mo><msub><mi mathvariant="italic">P</mi><mn>1</mn></msub><mo mathvariant="italic">.</mo><msub><mi mathvariant="italic">P</mi><mn>2</mn></msub><mo mathvariant="italic">...</mo><msub><mi mathvariant="italic">P</mi><mi mathvariant="normal">n</mi></msub></mfenced><mo mathvariant="italic">:</mo><mi mathvariant="italic">HDR</mi><mo mathvariant="italic">.</mo><msub><mi mathvariant="italic">GK</mi><mi mathvariant="italic">old</mi></msub><mfenced open="{" close="}"><msub><mi mathvariant="italic">ID</mi><mrow><mi mathvariant="italic">n</mi><mo mathvariant="italic">+</mo><mn>1</mn></mrow></msub></mfenced></math><img file="EP1793525A1_D0014.tif" /></maths>the group of network elements. The accession process is aborted. The group can continue to use the same session key.

<u style="single">Renewal of the group key</u>

On a successful authentication, the network element is renewed <i>P_i</i> the group key. The new group key<i>GK_New</i> is generated randomly and is independent of the previous ones. The token holder sends the new group key with the multicast message<i>M_j5</i> to the extended group. For the exchange of<i>M_j5</i> the transmission channels explained above are used. <i>M_j5</i> has the following structure: <maths id="math0015" num=""><math display="block"><msub><mi>M</mi><mrow><mi>j</mi><mo>⁢</mo><mn>5</mn></mrow></msub><mo>⁢</mo><mfenced separators=""><msub><mi>P</mi><mi>i</mi></msub><mo>→</mo><msub><mi>P</mi><mn mathvariant="italic">1</mn></msub><mo>.</mo><msub><mi>P</mi><mn mathvariant="italic">2</mn></msub><mo>...</mo><msub><mi>P</mi><mrow><mi>n</mi><mo>+</mo><mn mathvariant="italic">1</mn></mrow></msub></mfenced><mo>:</mo><mi mathvariant="italic">HDR</mi><mo mathvariant="italic">.</mo><msub><mi mathvariant="italic">GK</mi><mi mathvariant="italic">old</mi></msub><mfenced open="{" close="}" separators=""><msub><mi mathvariant="italic">ID</mi><mrow><mi>i</mi><mo>.</mo></mrow></msub><mo>⁢</mo><msub><mi>N</mi><mi>i</mi></msub></mfenced><mo>.</mo><msub><mi>K</mi><mrow><mi>i</mi><mo>⁢</mo><mn mathvariant="italic">1</mn></mrow></msub><mfenced open="{" close="}" separators=""><mi mathvariant="italic">VK</mi><mo>⁢</mo><msub><mi mathvariant="italic">GK</mi><mi mathvariant="italic">New</mi></msub></mfenced><mo>.</mo><mo>...</mo><mo>.</mo><msub><mi mathvariant="italic">K</mi><mi mathvariant="italic">in</mi></msub><mfenced open="{" close="}" separators=""><mi mathvariant="italic">VK</mi><mo>⁢</mo><msub><mi mathvariant="italic">GK</mi><mi mathvariant="italic">New</mi></msub></mfenced><mo>.</mo><mi mathvariant="italic">SK</mi><mfenced open="{" close="}" separators=""><msub><mi mathvariant="italic">GK</mi><mi mathvariant="italic">New</mi></msub><mo>⁢</mo><mi mathvariant="italic">VK</mi><mo>⁢</mo><mi mathvariant="italic">GSA</mi><mo>⁢</mo><msub><mi mathvariant="italic">ID</mi><mi mathvariant="italic">i</mi></msub></mfenced><mo>.</mo><msub><mi mathvariant="italic">GK</mi><mi mathvariant="italic">New</mi></msub><mfenced open="{" close="}" separators=""><msup><mi>G</mi><mrow><mi mathvariant="italic">rn</mi><mo>+</mo><mn>1</mn></mrow></msup><mo>⁢</mo><msub><mi mathvariant="italic">ID</mi><mrow><mi>n</mi><mo>+</mo><mn mathvariant="italic">1</mn></mrow></msub></mfenced></math><img file="EP1793525A1_D0015.tif" /></maths>

The message has four parts that serve different purposes. A first part<i>GK_old {ID_i, N_i}</i> Contains the identity of the token holder <i>ID_i</i> as well as a random number N and is using the old group key <i>GK_old</i> encrypted. Both elements are used to build the secure channel according to formulas (2) and (3).

A second message part <i>K_il {VK, GK_new},</i> ..., <i>K_in {VK, GK_new</i>} contains the new group key <i>GK_New</i> and a numeric value for a current version number <i>VK.</i> Both elements are using the respective key of the secret transmission channel <i>K_ij (j = 1, 2,</i> ..., <i>n</i> With <i>j ≠ i)</i> encrypted separately for each group member. Upon receipt, the network element, using the information from the first message part, calculates the current keys of its channel and decrypts its part.

A third message part <i>SK {GC_New, UK, GSA, ID_i}</i> transmits the group key <i>GK_New</i> and its version number <i>VK</i> to the new network element. Furthermore, a security associations of the group<i>GSA</i> as well as the <i>ID</i> of the token holder so that the new network element recognizes the token holder as sender. This message part is used with the session key agreed during the authentication phase<i>SK</i> encrypted.

A fourth message part <i>GK_New (G^{rn + 1} , ID_{n + 1}},</i> the one with the new group key <i>GK_New</i> is encrypted, contains the identity of the new network element <i>ID</i>_{n + 1} and its public DH value <i>G^{rn + 1},</i> After the decryption of the fourth message part and the calculation of the two-sided DH secret with the new network element, all group members again have the same information, ie they are able to renew the group key in the manner described when assigning the virtual token ,

<i>Leaving a network element ("Leave procedure</i> ")

When a network element leaves the group of network elements, the group management informs the remaining group members about it. The group members determine according to formula (1) the new token holder, and this starts the renewal of the group key. Fig. 4 shows an example of this.

It is assumed that the network element <i>P</i>_{<i>n</i>+<i>1</i>} a group of <i>n</i>+<i>1</i> Leaves network elements. <i>P</i>_i be the token holder again. The key renewal begins again with the token holder having a new group key<i>GK_New</i> generated and with the message <i>M_L1</i> multicast to the remaining group members. <i>M_L1</i> has a similar structure to the join message <i>M_j5 :</i><maths id="math0016" num=""><math display="block"><msub><mi>M</mi><mrow><mi mathvariant="normal">L</mi><mo>⁢</mo><mn>1</mn></mrow></msub><mrow><mo>(</mo><msub><mi>P</mi><mi>i</mi></msub><mo>→</mo><msub><mi>P</mi><mn>1</mn></msub><mo>.</mo><msub><mi>P</mi><mn>2</mn></msub><mo>...</mo><msub><mi>P</mi><mi mathvariant="normal">n</mi></msub><mo>)</mo><mo>:</mo><mi mathvariant="italic">HDR</mi><mo mathvariant="italic">.</mo><msub><mi mathvariant="italic">GK</mi><mi mathvariant="italic">old</mi></msub><mfenced open="{" close="}" separators=""><msub><mi mathvariant="italic">ID</mi><mrow><mi mathvariant="normal">i</mi><mo>.</mo></mrow></msub><mo>⁢</mo><msub><mi>N</mi><mi mathvariant="normal">i</mi></msub></mfenced><mo>.</mo><msub><mi>K</mi><mrow><mi mathvariant="normal">i</mi><mo>⁢</mo><mn mathvariant="normal">1</mn></mrow></msub><mrow><mo>{</mo><mi mathvariant="italic">VK</mi><mo mathvariant="italic">.</mo><msub><mi mathvariant="italic">GK</mi><mi mathvariant="italic">New</mi></msub><mo>}</mo><mo>.</mo><mo>...</mo><mo>.</mo><msub><mi>K</mi><mi>in</mi></msub><mfenced open="{" close="}" separators=""><mi mathvariant="italic">VK</mi><mo>⁢</mo><msub><mi mathvariant="italic">GK</mi><mi mathvariant="italic">New</mi></msub></mfenced></mrow></mrow></math><img file="EP1793525A1_D0016.tif" /></maths>

The message <i>M_j5</i> contains first again the identity of the token holder and a random number for the renewal of the keys <i>K_ij (j</i> = 1, 2, ..., n with <i>j</i> ≠ <i>i)</i> for the separate secret channels according to relations (2) and (3). Both elements are encrypted with the old group key. The new group key<i>GK_New</i> and the current key version <i>VK</i> are encrypted with the key of the respective channel.

The network element leaving the group may not be in possession of the new group key <i>GK_New</i> as it is unable to access the secret channels without knowing the two-sided secrets <i>G^rir1,G^rir2.</i> ... <i>G^rirn</i> between the token holder and the other members of the group of network elements. When the remaining group members receive the message<i>M_L1</i> you can decrypt these, like the one above for the message <i>M_j5</i> has been described.

In the method proposed here, the position of the virtual token is known at all times. Also, changes in position with a change in group composition can be accurately determined. As a special case, the failure of a network element, including that of the token holder, must now be considered. This change in group composition is signaled to the security layer not by group management but by the group management protocol that detects the failure. From the expiry of the failure of a network element corresponds to the exit of a group member. After the failure is reported, the group members behave as in the previously described exit <i>( "Leave procedure</i> ").

<u style="single">security analysis</u>

In the following it will be explained how safety requirements are met by the described method.

<i>Key Authentication:</i> Access to the group key from outside the group of network elements is prevented, on the one hand, by checking each new group member for identity before joining. Only if this check is successful does the new network element receive the group key. Conversely, the joining network element checks on the basis of the message<i>M_j3</i> transmitted signature that the transmitted identities and public DH values ​​are really attributable to the group to be joined. The key renewal procedure ensures that the new group key can only be delivered to the current group by using secret channels derived from the two-sided DH secrets of the authenticated members.

<i>Forward confidentiality:</i> The further confidentiality is secured by the procedure when a network element leaves the group. A leaving group member can not gain access to the new group key because, due to the lack of knowledge of the two-sided DH secrets and the newly generated random number, it can not gain access to the secret channels between the token holder and remaining members through which the new group key is distributed.

<i>Backward confidentiality:</i> Retroactive confidentiality is achieved by having the old group key join the joining network element with the message <i>M_j5</i> not delivered. The message parts of<i>M_j5.</i> that can be decrypted with the new key do not contain the old group key.

<i>Collusion freedom:</i> A secret agreement between participating network elements to uncover the current group key is avoided in that each newly generated group key is not related to the previous group keys, so that the network elements involved can not use their old group keys for detection.

<i>Perfect Forward Secrecy:</i> A permanent secrecy of a completed session is not guaranteed if a long-term credential (credential) is compromised or an active attacker succeeds in uncovering older group keys. The proposed method only provides for a long term credential, the private RSA key used during the authentication phase. However, the RSA key pair is never used for encryption of the group key, so that the owner with a compromised RSA key can not get to the group key. The second case is relevant only if a meeting consists of multiple sessions using different session keys. Here is an example of such a meeting consisting of four sessions. The group key is renewed for each session. As a result, each session is characterized by its session keys and associated key materials as indicated in Table 1 below.<tables id="tabl0001" num="0001"><table frame="all"><title>Table 1</title><tgroup cols="5"><colspec colnum="1" colname="col1" colwidth="80mm" /><colspec colnum="2" colname="col2" colwidth="19mm" /><colspec colnum="3" colname="col3" colwidth="19mm" /><colspec colnum="4" colname="col4" colwidth="19mm" /><colspec colnum="5" colname="col5" colwidth="19mm" /><thead><row><entry align="center" valign="top"><b>key materials</b></entry><entry align="center" valign="top"><b>Session 1</b></entry><entry align="center" valign="top"><b>Session 2</b></entry><entry align="center" valign="top"><b>Session 3</b></entry><entry align="center" valign="top"><b>Session 4</b></entry></row></thead><tbody><row><entry>group key <i>(GK)</i></entry><entry align="center"><i>GK₁</i></entry><entry align="center"><i>GK₂</i></entry><entry align="center"><i>GK₃</i></entry><entry align="center"><i>GK₄</i></entry></row><row><entry>Zeitweitliger secret key <i>K_ij</i> between <i>P_i</i> and <i>P_j</i></entry><entry align="center"><i>K_ij1</i></entry><entry align="center"><i>K_ij2</i></entry><entry align="center"><i>K_IJ3</i></entry><entry align="center"><i>K_IJ4</i></entry></row><row><entry>random number <i>(N_i)</i></entry><entry align="center"><i>N_i1</i></entry><entry align="center"><i>N_i2</i></entry><entry align="center"><i>N_i3</i></entry><entry align="center"><i>N_i4</i></entry></row><row><entry>Shared secret of <i>P_i</i> u<i>, P_j</i></entry><entry align="center"><i>G^rirj</i></entry><entry align="center"><i>G^rirj</i></entry><entry align="center"><i>G^rirj</i></entry><entry align="center"><i>G^rirj</i></entry></row><row><entry>Secret DH value of <i>pi</i></entry><entry align="center"><i>r_i</i></entry><entry align="center"><i>r_i</i></entry><entry align="center"><i>r_i</i></entry><entry align="center"><i>r_i</i></entry></row></tbody></tgroup></table></tables>

All key materials except the common secrets (g^rirj) between <i>P</i>_i and the other members <i>P_j</i> (<i>j</i> = 1, 2 ..., n with <i>j ≠ i</i>) and their secret DH values ​​are replaced with new values ​​for each session. According to the above formulas (2) and (3), the timeliness of the temporary secret group keys depends largely on the random number<i>N_i</i> from. Since each session uses a different, group key, each one also has a different value<i>N_i</i> used for generation. If we now assume that an attacker succeeds in the network element<i>P_i</i> while Session 3 breaks in and gains access to the key materials highlighted in gray in the above table, it still can not acquire the keys of previous sessions. For this he needs the random number<i>N₂,</i> This is however with the group key <i>GK₁</i> (see news <i>M_j5</i> and <i>M_L1</i> above) encrypted. If the attacker<i>GK₂</i> he wants to uncover <i>GK₁,</i> The latter does not exist anymore in the system. The same applies to the detection of<i>GK₁,</i> The attacker would therefore not be able to break completed sessions.

<i>Resistance to known key attacks:</i> Resistance to attacks with known group keys means that a revealed group key can not be used to compromise the current session key. Here are again two cases to distinguish (<nplcit id="ncit0016" npl-type="b"><text>AJ Menezes et al .: Handbook of Applied Cryptography, CRC Press Series on Discrete Mathematics and Its Applications, CRC Press, 1997</text></nplcit>).

The first case looks at the passive attacker who records the communication and analyzes it later. It is assumed that the passive attacker has the previous keys and the random number N for the generation of the temporary secret key<i>K_ij</i> between two partners. That is not enough. To generate the key, he needs the common DH secret of the partners. However, these are never transmitted over the connection. The other case concerns the active attacker trying to change the data on the connection. We consider here the situation that the token holder<i>P_i</i> the group key by sending the messages <i>M_j5</i> or <i>M_L1</i> renewed. Furthermore, we assume that the active attacker somehow possesses the old group key<i>GK_old</i> has arrived, so that he <i>M_j5</i> or <i>M_L1</i> could catch and with the help of <i>GK_old</i> could change the message as follows:<tables id="tabl0002" num="0002"><table frame="none"><tgroup cols="3" colsep="0"><colspec colnum="1" colname="col1" colwidth="33mm" /><colspec colnum="2" colname="col2" colwidth="34mm" /><colspec colnum="3" colname="col3" colwidth="33mm" /><thead><row><entry valign="top"><i>P_i</i> token holder</entry><entry valign="top">Active attacker</entry><entry valign="top">receiver <i>P₁</i></entry></row></thead><tbody><row rowsep="0"><entry align="center"><i>HDR, GK_old{ID_i, N_i},</i></entry><entry align="center"><i>HDR, GK_old{ID_i', N_i '},</i></entry><entry align="center"><i>HDR, GK_old{ID_i', N_i'},</i></entry></row><row><entry rowsep="0" align="right">→</entry><entry rowsep="0" align="right">→</entry><entry rowsep="0" /></row><row><entry rowsep="0" align="center"><i>K_il{FK, GK_New} ...</i></entry><entry rowsep="0" align="center"><i>K_il{FK, GK_New} ...</i></entry><entry rowsep="0" align="center">K_il{FK, GK_New} ...</entry></row></tbody></tgroup></table></tables>

The attacker replaced <i>ID;</i> and <i>N_i</i> through another identity <i>ID_i</i> and random number <i>N_i,</i> However, the fake message would cause recipients to generate other temporary secret keys <i>K_ij</i> lead, however, by authenticating the message part <i>{VK, GK_New}</i> by means of incorrect key <i>K_ij</i> is revealed. So if an attacker with an older key falsifies parts of the message, then the group members recognize the attack.

To evaluate the performance of the proposed method, this will be described below with that of Rodeh et al. proposed key distribution protocol (cf.<nplcit id="ncit0017" npl-type="s"><text>O. Rodeh et al.: Optimized Group Re- key for Group Communication Systems. In Symposium Network and Distributed System Security (NDSS), San Diego, California, Feb. 2000, pp. 39-48</text></nplcit>) and the most efficient key agreement protocol TKDH (cf. <nplcit id="ncit0018" npl-type="b"><text>Y. Kim et al .: Simple and fault-tolerant key agreement for dynamic collaborative groups, in S. Jajodia (ed.): 7th ACM Conference on Computer and Communications Security, Athens, Greece, Nov. 2000, ACM Press, p. 235-244</text></nplcit>) compared. For the comparison, a benchmark for cryptographic algorithms is used (see Crypto ++ 5.2.1 Benchmarks http://www.eskimo.com/~weidai/benchmarks.html). The comparison is broken down into the authentication and the key renewal part.

Authentication is included only in the method proposed here, but not in the two comparison protocols, which is why only the effort for VTKD can be specified here. The effort for the authentication results from the calculation costs for the four messages<i>M_j1~ M_j4</i> and the additional calculation of two-sided DH secrets. According to the IKEv2 standard, the calculation costs include the cost of calculating two RSA signatures, verifying two signatures, four symmetric cryptographic operations, and four hash mappings. The extra effort for calculating the<i>n</i> DH secrets are much stronger. For groups up to 100 participants, as provided for VTKD, the benchmark results in a calculation time of 386ms, which would be acceptable. Actually, this calculation can be "<i>offline"</i> because the DH secrets are not needed during the authentication phase, but only at the key renewal for the secret channels.

An accepted criterion for assessing the efficiency of key exchange protocols is the time between the initiation of a key renewal and the availability of the new key to all subscribers. This delay is mainly determined by the communication and calculation effort. These two aspects are considered below for the protocols to be compared.

The communication effort relates to the number of communication rounds and the size of the messages. They are summarized in Table 1 for the three protocols. For VTKD and TGDH the communication effort is low because only one multicast message is sent out for joining and leaving. Rodeh's protocol requires several communication rounds for leaving the group. Regarding message size, the Rodeh protocol has the advantage. It sends only small messages, while the message sizes at VTKD for 100 members 4 Kbyte and for TGDK even 25 Kbyte. However, that's not a big deal, as 25 KB can be easily accommodated in a UDP package.<tables id="tabl0003" num="0003"><table frame="all"><title>Table 2</title><tgroup cols="7"><colspec colnum="1" colname="col1" colwidth="21mm" /><colspec colnum="2" colname="col2" colwidth="19mm" /><colspec colnum="3" colname="col3" colwidth="39mm" /><colspec colnum="4" colname="col4" colwidth="18mm" /><colspec colnum="5" colname="col5" colwidth="28mm" /><colspec colnum="6" colname="col6" colwidth="16mm" /><colspec colnum="7" colname="col7" colwidth="27mm" /><thead><row><entry morerows="1" valign="top">protocol</entry><entry morerows="1" valign="top">surgery</entry><entry namest="col3" nameend="col7" align="center" valign="top">communication effort</entry></row><row><entry align="center" valign="top">communication rounds</entry><entry align="center" valign="top">multicast</entry><entry align="center" valign="top">Size of the multicast message</entry><entry align="center" valign="top">unicast</entry><entry align="center" valign="top">Size of unicast message</entry></row></thead><tbody><row><entry>Rodeh et al.</entry><entry>accession</entry><entry align="center">2</entry><entry align="center">2</entry><entry align="center">log₂<i>n</i>¹⁾ symmetrical keys²⁾</entry><entry align="center">1</entry><entry align="center">1 symmetric key</entry></row><row>&lt;entry /&gt;<entry>exit</entry><entry align="center">log₂<i>n</i></entry><entry align="center">log₂<i>n</i></entry><entry align="center">log₂<i>n</i> symmetrical keys</entry><entry align="center">log₂<i>n</i></entry><entry align="center">1 symmetric key</entry></row><row><entry>TGDH</entry><entry>accession⁴⁾</entry><entry align="center">1</entry><entry align="center">1</entry><entry align="center">2n asymmetric keys³⁾</entry><entry align="center">1</entry><entry align="center">1 symmetric key</entry></row><row>&lt;entry /&gt;<entry>exit</entry><entry align="center">1</entry><entry align="center">1</entry><entry align="center">log₂n asymmetric keys</entry><entry align="center">-</entry><entry align="center">-</entry></row><row><entry>VTKD</entry><entry>accession</entry><entry align="center">1</entry><entry align="center">1</entry><entry align="center"><i>n</i> symmetrical keys +1 asymmetric key</entry><entry align="center">-</entry><entry align="center">-</entry></row><row>&lt;entry /&gt;<entry>exit</entry><entry align="center">1</entry><entry align="center">1</entry><entry align="center"><i>n</i> symmetrical keys</entry><entry align="center">-</entry><entry align="center">-</entry></row></tbody></tgroup><tgroup cols="7" rowsep="0"><colspec colnum="1" colname="col1" colwidth="21mm" /><colspec colnum="2" colname="col2" colwidth="19mm" /><colspec colnum="3" colname="col3" colwidth="39mm" /><colspec colnum="4" colname="col4" colwidth="18mm" /><colspec colnum="5" colname="col5" colwidth="28mm" /><colspec colnum="6" colname="col6" colwidth="16mm" /><colspec colnum="7" colname="col7" colwidth="27mm" /><tbody><row><entry namest="col1" nameend="col7" align="justify">Legend: 1) <i>n</i> is the number of group members. 2) The typical size of a symmetric key is 128 bit = 16bytes. 3) The typical size of an asymmetric key is 1024 bits = 128 bytes. 4) Joining TGDH requires two rounds of communication, but only one round of communication is key renewal.</entry></row></tbody></tgroup></table></tables>

Table 3 shows the computational burden of the protocols by indicating the different cryptographic operations they use. The comparison shows that the protocols use asymmetric and symmetric operations differently. While TGDH performs intensive asymmetric calculations on the one hand, the method proposed here primarily uses symmetric operations. Rodeh's protocol is in between. As is well known, asymmetric cryptographic computations are much slower than symmetric ones, so the overall computational effort of VTKD is less than that of the other protocols.<tables id="tabl0004" num="0004"><table frame="all"><title>Table 3</title><tgroup cols="8"><colspec colnum="1" colname="col1" colwidth="18mm" /><colspec colnum="2" colname="col2" colwidth="19mm" /><colspec colnum="3" colname="col3" colwidth="36mm" /><colspec colnum="4" colname="col4" colwidth="31mm" /><colspec colnum="5" colname="col5" colwidth="27mm" /><colspec colnum="6" colname="col6" colwidth="30mm" /><colspec colnum="7" colname="col7" colwidth="41mm" /><colspec colnum="8" colname="col8" colwidth="43mm" /><thead><row valign="middle"><entry morerows="1" align="center">protocol</entry><entry morerows="1" align="center">surgery</entry><entry morerows="1" align="center">members</entry><entry namest="col4" nameend="col8" align="center">computational effort</entry></row><row valign="middle"><entry align="center">DH secrets⁴⁾</entry><entry align="center">RSA signature⁵⁾</entry><entry align="center">RSA verification⁵⁾</entry><entry align="center">Hash and symmetric encryption</entry><entry align="center">Hash and symmetric decryption</entry></row></thead><tbody><row><entry morerows="5" align="center" valign="middle">Rodeh</entry><entry morerows="2" align="center" valign="middle">accession</entry><entry>Head of the tree</entry><entry align="center">1</entry><entry align="center">-</entry><entry align="center">-</entry><entry align="center">2</entry><entry align="center">-</entry></row><row><entry>New member</entry><entry align="center">1</entry><entry align="center">-</entry><entry align="center">-</entry><entry align="center">-</entry><entry align="center">1</entry></row><row><entry>Member</entry><entry align="center">-</entry><entry align="center">-</entry><entry align="center">-</entry><entry align="center">-</entry><entry align="center">1</entry></row><row><entry morerows="2" align="center" valign="middle">exit</entry><entry>Head of the tree</entry><entry align="center">log₂n¹⁾</entry><entry align="center">-</entry><entry align="center">-</entry><entry align="center">log₂n</entry><entry align="center">-</entry></row><row><entry>Head of the subtree</entry><entry align="center">1</entry><entry align="center">-</entry><entry align="center">-</entry><entry align="center">-</entry><entry align="center">1</entry></row><row><entry>Member</entry><entry align="center">-</entry><entry align="center">-</entry><entry align="center">-</entry><entry align="center">-</entry><entry align="center">1</entry></row><row><entry morerows="4" align="center" valign="middle">TGDH²⁾</entry><entry morerows="2" align="center" valign="middle">accession</entry><entry>sponsor</entry><entry align="center">2 log₂n</entry><entry align="center">1</entry><entry align="center">-</entry><entry align="center">-</entry><entry align="center">-</entry></row><row><entry>New member</entry><entry align="center">2 log₂n</entry><entry align="center">-</entry><entry align="center">1</entry><entry align="center">-</entry><entry align="center">-</entry></row><row><entry>Member</entry><entry align="center">1 ... 2log₂n</entry><entry align="center">-</entry><entry align="center">1</entry><entry align="center">-</entry><entry align="center">-</entry></row><row><entry morerows="1" align="center" valign="middle">exit</entry><entry>sponsor</entry><entry align="center">2 log₂n</entry><entry align="center">1</entry><entry align="center">-</entry><entry align="center">-</entry><entry align="center">-</entry></row><row><entry>Member</entry><entry align="center">1 ... 2 log₂n</entry><entry align="center" /><entry align="center">1</entry><entry align="center">-</entry><entry align="center">-</entry></row><row><entry morerows="4" align="center" valign="middle">VTKD³⁾</entry><entry morerows="2" align="center" valign="middle">accession</entry><entry>token owner</entry><entry align="center">-</entry><entry align="center">-</entry><entry align="center">-</entry><entry align="center">n + 3</entry><entry align="center">-</entry></row><row><entry>New member</entry><entry align="center">-</entry><entry align="center">-</entry><entry align="center">-</entry><entry align="center">-</entry><entry align="center">2</entry></row><row><entry>Member</entry><entry align="center">1</entry><entry align="center">-</entry><entry align="center">-</entry><entry align="center">-</entry><entry align="center">3</entry></row><row><entry morerows="1" align="center" valign="middle">exit</entry><entry>token owner</entry><entry align="center">-</entry><entry align="center">-</entry><entry align="center">-</entry><entry align="center">n + 2</entry><entry align="center">-</entry></row><row><entry>Member</entry><entry align="center">-</entry><entry align="center">-</entry><entry align="center">-</entry><entry align="center">-</entry><entry align="center">2</entry></row></tbody></tgroup><tgroup cols="8" rowsep="0"><colspec colnum="1" colname="col1" colwidth="18mm" /><colspec colnum="2" colname="col2" colwidth="19mm" /><colspec colnum="3" colname="col3" colwidth="36mm" /><colspec colnum="4" colname="col4" colwidth="31mm" /><colspec colnum="5" colname="col5" colwidth="27mm" /><colspec colnum="6" colname="col6" colwidth="30mm" /><colspec colnum="7" colname="col7" colwidth="41mm" /><colspec colnum="8" colname="col8" colwidth="43mm" /><tbody><row><entry namest="col1" nameend="col8" align="justify">Legend: 1) <i>n</i> is the number of group members. 2) It is considered the best case of a balanced key tree for TGDH. The worst case requires<i>n</i> DH-secret considerations. 3) Here the calculation effort for the group key renewal is shown, in which the creation of the messages <i>M_j5</i> and <i>ML₁</i> occurs in VTKD. 4) A DH secret calculation means an exponential calculation. 5) RSA signature in TGDH is used for message authentication.</entry></row></tbody></tgroup></table></tables>

With the tables 2 and 3 can now the delay of the key renewal <i>dg_kr</i> be determined as follows: <maths id="math0017" num="(4)"><math display="block"><msub><mi>D</mi><mi>GKR</mi></msub><mo>=</mo><msub><mi>D</mi><mi>cs</mi></msub><mo>+</mo><msub><mi>D</mi><mi>gc</mi></msub><mo>+</mo><msub><mi>D</mi><mi>cr</mi></msub></math><img file="EP1793525A1_D0017.tif" /></maths>in which <i>D</i>_cs and <i>D</i>_cr the sender's cryptographic computation delay and Dgc the communication delay.

For comparison, it is further assumed that all protocols are running over the same group communication protocol that produces a 20ms delay for each communication round. This is a typical delay in mid-sized networks, such as the G-WiN, where we measured a maximum round trip time of 40ms to any node. The calculation delay for the sender and receiver was again determined using the cryptographic benchmark Crypto ++ 5.2.1 Benchmarks http://www.eskimo.com/~weidai/benchmarks.html.

The overall delays for key renewal to join and leave the group are shown in FIG. VTKD is more efficient than the other two protocols. The reason for this is that VTKD requires fewer communication rounds than the other two and uses predominantly symmetric encryption operations.

The efficient and secure key renewal forms a basis for confidential communication in closed dynamic groups. Such applications are especially in the business area, where increasingly negotiations and consultations are also handled via the Internet. For centralized approaches with a group server there are practicable approaches. With the increasing use of mobile communication solutions are increasingly in demand that dispense with a group server and support peer-to-peer communication of partners. This especially supports ad hoc meetings. The methods used must be efficient, since apart from the key distribution and audio / video encryption with the compression and decompression of the media data, other time- and resource-intensive processes run on the end systems. The scaling of the protocol is less the problem for such applications but the efficiency and security of the process.

The features of the invention disclosed in the foregoing description, in the claims and in the drawing may be of importance both individually and in any combination for the realization of the invention in its various Ausführungsfbrmen.