A Fault-Tolerant Authenticated Key-Conference Agreement Protocol with Forward Secrecy

Abstract

In conference channels, users communicate with each other using a conference key that is used to encrypt messages. There are two basic approaches in which the key can be established. In the first one, a central server is used (with a chairman role). The server generates the key and distributes it to participants. The second approach is that all participants compute a key without a chairman. In this paper, we introduce a special type of group authentication using secret sharing, which provides an efficient way to authenticate multiple users belonging to the same group without the chairman. Our proposed protocol is a many-to-many type of authentication. Unlike most user authentication protocols that authenticate a single user each time, our proposed protocol authenticates all users of a group at once.

1 Introduction

In the era of mobile devices and cloud computing, millions of documents and messages are continuously exchanged over the Internet. The communication channels built using the Internet require security measures that will ensure confidentiality and entities’ authentication. Communication channels can be divided into three types: one-to-one, one-to-many (broadcast channels) and many-to-many (conference channels) allowing message exchange between all participants.

Several protocol allowing mutual user authentication and key derivation exists. One of the most popular TLS (Transport Layer Security) is widely used in many kinds of different applications. Situation is more complicated when we need a conference channel. Of course, protocols like TLS can be used to simulate a conference channel by creating independent channels between users. However, when a number of users increases this starts to be infeasible, because the number of channels and exchanged messages increase quadratically.

In conference channels, users communicate with each other using a conference key K that is used to encrypt messages [1]. There are two basic approaches in which the key K can be established. In the first one, a central server is used (with a chairman role). The server generates the key and distributes it to participants. The second approach is that all participants compute a key without a chairman. The first approach is simpler and easier to implement, but it lacks of flexibility and requires an additional service. The second approach is a special case of a secure multiparty computation in which a group of people evaluate securely a function to f(k₁, k₂, …), with each person possessing a private input k_i. The conference key agreement protocols have a few different features in comparison with secure multiparty computation. Firstly, private channels between participants are not available. Secondly, the main goal of an adversary is to disrupt the protocol between honest participants. Thirdly, a cheater is excluded from participating when is found (the cheater secret is not necessary to compute the conference key) [1].

The conference-key agreement protocols have several properties [2, 3]:

• (a) Forward confidentiality– subsequent conference keys cannot be obtained by participants who left the conference sessions [3, 4].

• (b) Backward confidentiality – former conference keys cannot be obtained by participants who joined the conference session [3, 4].

• (c) Key freshness – If a conference-key agreement protocol achieves both backward and forward confidentiality, then the key generated using this protocol is called fresh [3, 4].

• (d) Forward secrecy - A conference-key agreement protocol provides forward secrecy if the long-term secret key x_i of any participant U_i is compromised, but will not result in the compromise of previously established conference keys [5–7]. Forward secrecy is different from forward confidentiality as it is related to a long-term key in opposite to forward confidentiality that is related to a short term conference key K.

• (e) Authentication – the protocol is called an authenticated protocol when it contains mechanism allowing detect if the participant is a member of the conference [2].

• (f) Fault tolerance – the protocol is called fault-tolerant when it detects faulty broadcast messages during the communication of participants. The sender of the faulty message is marked as possible malicious one. Faulty messages are re-verified and in a case of a negative result, the participant is excluded from the set of participants [2]. Such property allows honest participant to establish a conference key, even in malicious participant are trying to disrupt it [1, 8, 9].

• (g) Dynamic settings – The dynamic group operations supported by the protocol (i.e.: single or mass join, single or mass leave, merge or divide groups) [2].

Several conference protocols have been proposed in recent years. However, the DKCAP protocol with all mentioned above properties was presented in 2015 by Ermiş et al. [2]. Also, they have provided comprehensive comparison of the protocols. The protocol proposed by Chung in 2013 [10] have all the properties except fault tolerance and supports only two dynamic operations. In contrast, Cheng et al. [11] proposed a protocol that is fault tolerant, but does not provide forward secrecy. Zhao et al. [12] proposed protocol that is authenticated, fault tolerant, provides forward secrecy and key freshness, but does not have dynamin operations.

Authenticated, fault tolerant and providing key freshness protocols, without the forward secrecy and dynamin operations have been proposed by Huang et al. [13], Wu et al. [14], Wang [15]. Katz and Yung [16] proposed an authenticated protocol with forward secrecy and key freshness, but without fault tolerant property and dynamic operations. Tseng proposed two protocol, first one [17] with all the properties except dynamic operations and second one [3] with two dynamic operations, but without key freshness.

1.1 Objective

In this paper, we propose the improved authenticated conference key agreement protocol, called Forward-secrecy and Fault-tolerance Authenticated Conference-Key Agreement (FF-ACKA) protocol. FF-ACKA protocol is a modified version of an improved conference-key agreement protocol with forward secrecy (hereinafter in short ICKAP [2, 17]) for the static group of participants. The protocol is a provable secure conference-key agreement protocol with fault tolerance and forward secrecy. In addition, because the security of ICKAP protocol is preserved, FF-ACKA protocol is resistant against known attacks of a passive and an active adversary.

FF-ACKA protocol requires only a constant size message to be sent by each participant and has two rounds. Both rounds are authenticated by means of long-term certified asymmetric keys of participants. Hence, FF-ACKA protocol is resistant against a classic man-in-the-middle attacks.

Another contribution of this work is to provide a truly contributory group conference key, i.e., in the protocol, the conference key is established jointly by all members of the conference, and not by any single member. Furthermore, the calculation of each participant contribution, in contrast to other protocols (e.g., [2, 17]), is much less time-consuming.

1.2 Paper Organisation

The remainder of this paper is organized as follows. Section 2 contains description of a security model, definitions and notations. In Sect. 3 is described the proposed FF-ACKA protocol (A Fault-Tolerant Authenticated Key-Conference Agreement Protocol with Forward Secrecy). Next, in Sect. 4 the security analysis of FF-ACKA protocol is provided. The paper ends with conclusion.

2 Preliminaries

We adopt the system and security model, definitions, and notations similar to Tseng’s works ([3, 17], see also [2]).

2.1 System Model

In the system, each participant has a long-term private key and a corresponding public key. The public system parameters and each participant’s public key information with its certificate are stored in a public directory. All participants are connected using a broadcast network and can distribute messages to each other. The transmission between them should be protected and needs to establish a conference key to encrypt their communications. Below, we present two definition which is strongly related to FF-ACKA protocol given in Sect. 3.

Definition 1

(Conference Participants, [2]). Participant, participant set and their properties:

• (a) Each conference participant is an entity and denoted as U_i.

• (b) The participant list is represented as (U₁, U₂, …, U_n). Each participant knows all participants and theirs identities.

• (c) Participants in a conference session can be categorized in two groups. If a participant fully follows the protocol, it is called a honest participant, or if a participant tries to cheat other participants to miscalculate the key is called a malicious participants.

Definition 2

(Verification Matrix, [2]). Let U = {U₁, U₂, …, U_n} be the set of participants. During the execution of the protocol, participant U_j, which for 1 ≤ i ≤ n and i ≠ j has at least one verification matrix entry V_i,j = ‘Step4:failure’ or V_i,j = ‘Step5:failure’ with the proper credentials, is defined as a potential malicious participant until its malicious behaviour is proved in a fault detection and correction step. Otherwise, i.e., if the verification matrix entry V_i,j = ‘Step4:success’ or V_i,j = ‘Step5:success’, the participant is defined as honest participant.

2.2 Security Properties

Under the same definitions as used in Tzeng’s protocol [1], there are malicious adversaries. The first is a passive adversary (an eavesdropper) who is not a participant, but who tries to learn the conference key from the broadcast messages. The conference-key agreement protocol is secure against a passive attack, if a selected random value and the established conference key are computationally indistinguishable for an adversary. The second is an active adversary. This is an adversary that is also a participant and who tries to disrupt the establishment of a conference key among the honest participants. A conference-key agreement protocol is secure against an active adversary. Even if the adversary does not follow the protocol in any way, he still cannot disrupt the establishment of the conference key. The security of the conference key protocol discussed in the paper is based on the Discrete Logarithm (DL) problem.

3 The Proposed Protocol with Forward Secrecy

Our Forward-secrecy and Fault-tolerance Authenticated Conference-Key Agreement (FF-ACKA) protocol consists of three phases, including a parameter generation phase, long-term keys and a certificates’ generation phase, a temporary public-key distribution phase, a secret distribution and commitment phase, a sub-key computation and verification phase, a fault detection phase, and a conference key computation phase. These phases and theirs detailed structures are explained below.

The FF-ACKA protocol with a forward secrecy property uses a temporary public key to distribute keys, thus even the disclosure of the user’s secret key will not result in the compromise of previously established conference keys. The authenticity of the user’s temporary key can be verified by checking the signature on the key (hereinafter referred as a temporary certificate) generated with the long-term private key. Hence, each instance of the protocol uses both the static long-term public keys as well as the temporary public keys, which makes the protocol forward secure.

Without loss of generality, let U = {U₁, U₂, …, U_n} be the initial set of participants that want to establish a common conference key. Each U_i (i = 1, …, n), knows the set U. In FF-ACKA protocol, we assume that a conference can be started by the creator of U set who as a member of this set plays a role of a conference initiator.

3.1 Step 1: Setup

On input a security parameter λ ∈ Z, this algorithm runs as follows (see [18, 19]):

• (a) generates a random (λ + 1)-bit prime number p;

• (b) calculates a prime q number equal to q = (p − 1)/2;

• (c) chooses an arbitrary $x \in Z_{p}^{*}$ with $x \ne \pm 1\;\bmod p$ and sets $g = x^{2} \;\bmod p$; g is a generator for the subgroup $G_{q} \subset Z_{p}^{*}$;

• (d) chooses cryptographic hash functions (like as in [28]): $H:\left\{ {\,0,\;1\,} \right\}^{*} \to Z_{q}$, $G:\left\{ {\,0,\;1\,} \right\}^{*} \to Z_{q}$.

Hence, the system parameters are params = {G_q, Z_p, Z_q, p, q, g, H}.

3.2 Step 2: Keys and Long-Term Certificates Generation

We assume that each user U_i in the system makes the following operations:

• (a) picks an random integer $x_{i} \in Z_{q}^{*}$ as a private key and computes a public key y_i such that $y_{i} = g^{{x_{i} }} \;\bmod \,p \in Z_{p}^{*}$;

• (b) sends a certificate signing request to a certificate authority (CA) in order to apply for a digital identity certificate (e.g., in X.509 format) with the U_i’s certificate information $CI_{i}$, containing the CA’s identifiers $ID_{{U_{i} }}$ and $ID_{CA}$ of the user U_i and the TA, respectively, and the time period $\Delta \tau$ for which the information $CI_{i}$ is valid;

• (c) takes his certificate cert_i which was issued by CA.

The resulting public key is (p, q, g, y_i), while the private key has a form of (p, q, g, x_i). The authenticity of this key pair confirms the certificate cert_i issued by the CA. The protocol is started by the initiator who calls for a conference by initializing a set of participants U. In addition, the function of time stamp T is required, and it will be updated to a new one for each conference session.

3.3 Step 3: Temporary Public-Key Distribution

Each from n participants belonging to a set U generates a temporary key pair and issues certificate related to the key pair. The temporary certificate is signed by the user using his private key and is valid only for a period of the key establishment phase in the conference protocol.

We use the Galindo-Garcia signature scheme given in [20, 21] to generate a temporary certificate. This signature scheme is based on the discrete logarithm problem and is secure against the adaptively chosen message attack in the random oracle model.

The algorithm described below is executed by all users U_i ∈ U:

• (a) a user U_i select a short-term private key $t_{i} \in Z_{q}^{*}$ and an integer $v_{i} \in Z_{q}^{*}$ as a private key, and then computes a temporary public key $T_{i} = g^{{t_{i} }} \;\bmod \,p$ and $V_{i} = g^{{v_{i} }} \;\bmod \,p$;

• (b) a user U_i composes the user’s certificate information $tCI_{i}$, including the U_i’s public keys $T_{i}$, its identifier $ID_{i}$ and the short period $\Delta \tau$ for which the information $tCI_{i}$ is valid;

• (c) U_i computes a temporary certificate:

  $$ tCert_{i} = \left( {t_{i} + \left( {v_{i} + x_{i} h_{i} } \right)\,g_{i} } \right)\; mod \, q, $$

  (1)

  where $h_{i} = H\left( {tCI_{i} ,V_{i} ,T} \right)$ and $g_{i} = G\left( {T_{i} ,T,tCI_{i} ,h_{i} } \right)$ with the U_i’s certificate temporary information $tCI_{i}$ and broadcasts a message tM_i = ($tCert_{i}$, $tCI_{i}$, $T_{i}$, $V_{i}$, T, $\Delta \tau$) to each U group member.

Finally, the $tCert_{i}$ can be called as a certificate for the temporary public key T_i or a temporary certificate in short.

3.4 Step 4: Secret Distribution and Commitments

Upon receiving all messages $tM_{j} = \, (tCert_{j} ,tCI_{j} ,T_{j} ,V_{j} ,T,\Delta \tau )$, j = 1, …, i − 1, i + 1, …, n, each user U_i (1 ≤ i ≤ n) validates that $t_{j}$ is really issued by U_j, i.e., U_i verifies the time stamp T, computes $h_{j} = H\left( {tCI_{j} ,V_{j} ,T} \right)$, $g_{j} = G\left( {T_{j} ,T,tCI_{j} ,h_{j} } \right)$ and checks whether:

$$ g^{{tCert_{j} }} \equiv T_{j} \left( {V_{j} \left( {y_{j} } \right)^{{h_{j} }} } \right)^{{g_{j} }} \;\left( {mod \, p} \right) $$

(2)

The user U_i also validates whether:

• (a) the long-term certificate $cert_{j}$ related to the public key $y_{j}$ is authentic and unrevoked.

• (b) T_j is a generator of a subgroup G_q, i.e., if 2 ≤ T_j ≤ p − 1 and $\left( {T_{j} } \right)^{q} \;\bmod \,p = 1$.

If any check for tM_j of U_j does not hold, then the participant U_i sets V_i,j = ‘Step4:failure’, otherwise V_i,j = ‘Step4:success’. For both cases, the participant U_i computes credentials:

$$ h_{k,i} = H\left( {\left( {T_{k} } \right)^{{x_{i} }} \bmod \;q,\;V_{i,j} ,\;T} \right),\;k = 1, \ldots ,n;\;k \ne i, $$

(3)

and broadcasts a tuple vM_i,j = (V_i,j, h_1,i, …, h_i−1,i,, h_i+1,i, …, h_n,i, T). Next, if V_i,j = ‘Step4:failure’, the participant U_i goes to Step 6 for fault detection and correction. Otherwise, each participant U_i:

• (a) randomly selects a sub-key $K_{i} \in Z_{q}^{*}$ and a random linear function f_i(z) over $Z_{q}$:

  $$ f_{i} \left( z \right) = K_{i} + a_{i} z \in Z_{q} , $$

  (4)

  where the coefficient a_i is in $Z_{q}$;

• (b) calculates $\gamma_{i,0} = f_{i} \left( 1 \right)$, generates random numbers $\alpha_{i} ,\;\beta_{i} \in Z_{q}^{*}$, calculates $\Gamma _{i} = g^{{\alpha_{i} }} \bmod p$ and ${\rm B}_{i} = g^{{\beta_{i} }} \bmod p$, subsequently calculates for each j = 1, …, n; j ≠ i:

  • (a)
    $$ z_{i,j} = \left( {T_{j} } \right)^{{\,\alpha_{i} }} \bmod \;q $$
  • (b)
    $$ \gamma_{i,j} = f_{i} \left( {z_{i,j} } \right)\; \oplus H\left( {z_{i,j} ,\;tCert_{i} ,\;tCert_{j} } \right) $$

• (c) issues an attestation in a form:

  $$ \sigma_{i} = \left( {\alpha_{i} + \left( {\beta_{i} + t_{i} c_{i} } \right)\;d_{i} } \right)\; mod \, q $$

  (5)

  where $c_{i} = H\left( {{\rm B}_{i} ,\;T} \right)$, and $d_{i} = G\left( {\Gamma _{i} ,T,K_{i} ,c_{i} } \right)$; then sends each participant j (j ≠ i) a message M_i = ($\sigma_{i}$, $cert_{i}$, $tCert_{i}$, $\gamma_{i,0}$, $\gamma_{i,1}$, $\gamma_{i,2}$, $\ldots$, $\gamma_{i,n}$, $\Gamma _{i}$, ${\rm B}_{i}$).

Similarly as in step 3 (see Eq. 2), to issue a certificate a Galindo-Garcia signature scheme [20, 21] was used.

3.5 Step 5: Subkey Computation and Verification

Upon receiving message M_j = ($\sigma_{j}$, $cert_{j}$, $tCert_{j}$, $\gamma_{j,0}$, $\gamma_{j,1}$, $\gamma_{j,2}$, $\ldots$, $\gamma_{j,n}$, $\Gamma _{j}$, $\;{\rm B}_{j}$) from U_j (1 ≤ j ≤ n), each participant U_i for j ≠ i uses his short-term private key t_i to reconstruct the sub-key K_j as follows:

• (a) checks the time stamp T;

• (b) computes $z_{j,i} = \left( {\Gamma _{j} } \right)^{{t_{i} }} \;\bmod \;q$ and $f_{j} \left( {z_{j,i} } \right) = \gamma_{j,i} \oplus H\left( {z_{j,i} ,\;tCert_{j} ,\;tCert_{i} } \right)$;

• (c) calculates a sub-key:

  $$ K^{\prime}_{j} = f_{j} \left( 1 \right)\;\frac{{z_{j,i} }}{{z_{j,i} - 1}} + \frac{ - 1}{{z_{j,i} - 1}}f_{j} \left( {z_{j,i} } \right) \in Z_{q} $$

  (6)

• (d) checks if the following equality is fulfilled:

  $$ g^{{\sigma_{j} }} =\Gamma _{j} \left( {{\rm B}_{j} \left( {T_{j} } \right)^{{c^{\prime}_{j} }} } \right)^{{d^{\prime}_{j} }} \;\left( {mod \, p} \right) $$

  (7)

  where $c^{\prime}_{j} = H\left( {{\rm B}_{j} ,\;T} \right)$ and $d^{\prime}_{j} = G\left( {\Gamma _{j} ,T,K^{\prime}_{j} ,c^{\prime}_{j} } \right)$.

If it holds, a user U_i accepts a sub-key K_j = $K^{\prime}_{j}$ and sets V_i,j = ‘Step4:success’. Otherwise, a participant U_i sets Vi,j = ‘Step5:failure’. For both cases the participant U_i computes the credentials:

$$ r_{k,i} = H\left( {z_{k,i} ,\;V_{i,j} ,\;T} \right),\;k = 1, \ldots ,n;\;k \ne i, $$

(8)

and broadcasts a tuple $rM_{i,j} = (V_{i,j} ,r_{1,i} , \ldots ,r_{i - 1,i,} ,r_{i + 1,i} , \ldots ,r_{n,i} ,T)$.

3.6 Step 6: Fault Detection

All faults messages broadcasted by participants in steps 4 and 5 should be verified and corrected. Each participant Uj, which does not follow the protocol in any way, should be treated as possible malicious participants and marked as Vi,j = ‘StepX:failure’ in the verification matrix, where X = 4 or 5. Such approach is reasonable, because any malicious participant U_j can try to send the wrong evidences to other participants and disrupt the establishment of a conference key among the honest participants. The broadcast messages of possible malicious participants are re-verified by honest participants.

The broadcast messages of participants are verified in both secret distribution and commitment step (Step 4) and the sub-key computation and verification step (Step 5). Therefore, the fault messages in the FF-PA protocol that are sent by any malicious participant to other participants should be re-verified by honest ones.

Before the proper fault detection phase is started, each participant U_i (1 ≤ i ≤ n) on receiving the message vM_j,m or/and rM_j,m (see respective Step 4 and Step 5), first computes (for i ≠ j ≠ m):

$$ h^{\prime}_{i,j} = H\left( {\left( {y_{j} } \right)^{{t_{i} }} \;\bmod \;q,\;V_{j,m} ,\;T} \right), $$

(9)

or/and

$$ r^{\prime}_{i,j} = H\left( {\left( {\Gamma _{j} } \right)^{{t_{i} }} \;\bmod \;q,\;V_{j,m} ,\;T} \right), $$

(10)

and then verifies whether holds the equations $h^{\prime}_{i,j} \equiv h_{i,j}$ or/and $r^{\prime}_{i,j} \equiv r_{i,j}$. If the equation(s) are satisfied, then U_i starts the execution of the fault detection phase, or else, sets U_j as a malicious participant and restarts the protocol for new honest participant group U = U\{U_i}.

To detect and correct the faults, each participant $U_{i} \in U$ (i ≠ j ≠ m) receiving V_j,m acts in accordance to the following rules (compare also [2, 13, 22]):

• (a) if V_j,m = ‘Step4failure’ for any participant U_m, then other honest participants U_l, where 1 ≤ l ≤ n, re-verify the broadcast messages tM_m and if the verification result is still V_l,m = ‘failure:Step4’ (for any participant U_l), the participant U_l sets U_m as a malicious participant and goes to the step (c);

• (b) otherwise, if V_j,m = ‘Step5:failure’, the participants U_i knows that according to U_j the source of faulty is U_m (m ≠ i); hence U_i:

  • (i) waits for the fault detection message (α_m, a_m, K_m) from U_m;

  • (ii) sets U_m as a malicious participant and goes to the step (c), if no one receives the fault detection message from U_m;

  • (iii) checks whether previously distributed values (V_m, T_m, $tCert_{m}$, $\gamma_{m,0}$, $\gamma_{m,j}$, $\Gamma _{m}$, $B_{m}$, $\sigma_{m}$) are correct, i.e.:

    • checks whether α_m satisfies $\Gamma _{m} \equiv g^{{\alpha_{m} }} \bmod p$;

    • checks whether Eq. (1) holds for V_m, T_m and $tCert_{m}$;

    • inputs (a_m, K_m) into Eq. (4), calculates $z_{m,j} = \left( {T_{j} } \right)^{{\,\alpha_{m} }} \bmod \;q$ and checks whether:

      $$ \begin{aligned} & \gamma_{m,0} \equiv f_{m} \left( 1 \right) \\ & \gamma_{m,j} \equiv f_{m} \left( {z_{m,j} } \right)\; \oplus H\left( {z_{m,j} ,\;tCert_{m} ,\;tCert_{j} } \right) \\ \end{aligned} $$

    • verifies whether ($\Gamma _{m}$, $B_{m}$, $\sigma_{m}$) is the right signature on a sub-key K_m made by U_m (see Eq. (7)); if Eq. (7) holds, sets U_j as a malicious participant, otherwise, the malicious one is U_m.

• (c) removes the malicious participant (U_i or U_m) from the group U, i.e., the set of users is updated as U = U\{U_j}; similar operations are made by the other honest participants and finally the protocol is restarted.

3.7 Step 7: Conference-Key Computation

If no more faults are detected and all malicious participants are excluded from U, each honest participants U_i in the set of $U^{\prime} = \left\{ {\;U_{i,1} ,\;U_{i,2} ,\; \ldots ,\;U_{i,m} } \right\}$, where $m \le n$, may calculate the conference key K as follows:

$$ K = \left( {K_{i,1} + K_{i,2} + \; \ldots + K_{i,m} } \right)\;\bmod\;q. $$

(11)

4 Security Analysis

In this section, we give the security analysis of FF-ACKA protocol in fault tolerance and its forward secrecy. In the paper, a formal security analysis of the protocol is omitted. The formal analysis includes protocol resistance to passive and active attacks. Because of the similarity of the structures of the FF-ACKA and DCKAP [2] protocols, the security proof is similar to analysis presented in [2, 3].

For the fault tolerance analysis of FF-ACKA protocol we use the same approach as given in [1, 2, 13]. Let’s consider two general attack scenarios on FF-ACKA protocol (compare also [22]). In the first scenario, all participants may generate different conference keys, while in second one the honest participants can be excluded from the conference. Furthermore, we assume that an adversary A is able to alter the exchanged messages in the sub-key computation and verification phase.

Given the first scenario, the participant U_i is a malicious participant who sends a wrong message tM_j (Step 4) or M_j (Step 5). Suppose, that one of the honest participants U_j broadcasts message V_j,i = ‘Step4:failure’ or V_j,i = ‘Step5:failure’ after verifying the digital signature tCert_j (Eq. (3)) or $\sigma_{i}$ (Eq. (8)). However, an adversary A modifies the intercepting message V_j,i = ‘Step4:failure’ or V_j,i = ‘Step5:failure’ to V_j,i = ‘Step4:success’ or V_j,i = ‘Step5:success’ and broadcasts it to other participants. As a result, all participants compute and accept different conference keys.

For the second scenario, both U_i and U_j are honest participants in the set U. In Step 4 or Step 5 the participant U_j verifies receiving message tM_j (Step 4) or M_j (Step 5). If check holds, U_j broadcasts V_j,i = ‘Step4:success’ or V_j,i = ‘Step5:success’. However, like as in the first scenario, any adversary A can intercept this message and modify it to V_j,i = ‘Step4: failure’ or V_j,i = ‘Step5: failure’. It is obvious that all participants start the fault detection procedure and although the participants U_i is honest all participants remove it from the set of honest participants. Of course participant U_i should be removed from a set of honest participants, but only if U_i is indeed a malicious participant and sends out the fake message V_i,j = ‘Step4: failure’ or V_i,j = ‘Step5: failure’, declaring U_j who is actually honest as a malicious one.

In the following theorem, we demonstrate that the proposed protocol can provide fault tolerance.

Theorem 1

(Fault tolerance, [1, 2, 22]). If honest participants follow the protocol, they may compute the same conference key even if:

• (i) A malicious participant cheats the honest participants by sending wrong key values, and

• (ii) A malicious participant cheats the honest participants by identifying an honest participant as a possible malicious participant.

Proof.

For the first condition, assume that the participant U_i is a malicious participant and attempts to disrupt the establishment of a conference key among honest participants. The malicious participant U_i can use two methods of attacks. In first one, U_i broadcasts wrong messages in Step 4 or Step 5, while in second one U_i broadcasts the message V_i,j = ‘Step4: failure’ or V_i,j = ‘Step5:failure’ to claim that U_j is a malicious participant, although U_j is indeed a honest participant.

If U_i tries to cheat other honest participants in Step 4, then the broadcast messages tM_i = ($tCert_{i}$, $tCI_{i}$, $T_{i}$, $V_{i}$, T, $\Delta \tau$) are validated by each honest participant by checking whether $g^{{tCert_{i} }} \equiv T_{i} \left( {V_{i} \left( {y_{i} } \right)^{{h_{i} }} } \right)^{{g_{i} }} \;\left( {mod\,p} \right)$, where $h_{i} = H\left( {tCI_{i} ,V_{i} ,T} \right)$, $g_{i} = G\left( {T_{i} ,T,tCI_{i} ,h_{i} } \right)$, holds or not. If the message tM_i of U_i is wrong, at least one honest participant U_j (j ≠ i) is able to claim V_j,i = ‘Step4:failure’, because the wrong messages tM_i are unable to pass the validation. If U_i broadcasts wrong messages M_i in Step 5, each honest participant U_j can also validate the message M_i and concludes if the equations $g^{{\sigma_{i} }} =\Gamma _{i} \left( {{\rm B}_{i} \left( {T_{i} } \right)^{{c^{\prime}_{i} }} } \right)^{{d^{\prime}_{i} }} \,\left( {mod \, p} \right)$, where $c^{\prime}_{i} = H\left( {{\rm B}_{i} ,\;T} \right)$ and $d^{\prime}_{i} = G\left( {\Gamma _{i} ,T,K^{\prime}_{i} ,c^{\prime}_{i} } \right)$, holds or not. If the $K^{\prime}_{i}$ value is wrong the validations do not hold, and so any honest participant U_j can claim that V_j,i = ‘Step5:failure’.

Additionally, for both above presented forgeries assume that one of the honest participant U_j broadcasts message V_j,i = ‘Step4: failure’ or V_j,i = ‘Step5:failure’ after verifying the wrong message tM_i or M_i. However, an adversary A can intercept the message vM_j,i or rM_j,i sent by U_j and modify this message to $V^{\prime}_{j,i}$ = ‘Step4:success’ or $V^{\prime}_{j,i}$ = ‘Step5:success’, and then broadcasts it to all other participants.

Let’s take a closer look at above described adversary attack. It is easy to see that this type of attack is detected in the early stage of the fault detection phase. To show this, suppose that an adversary A replaces $V_{j,i}$ with $V^{\prime}_{j,i}$ and resends it to all other participants. On receiving $V^{\prime}_{j,i}$ and $h_{k,j}$ (Eq. (4)) or $r_{k,j}$ (Eq. (8)), any U_k (k ≠ i ≠ j) first computes $h^{\prime}_{k,j} = H\left( {\left( {y_{j} } \right)^{{\;t_{k} }} \bmod \;q,\;V^{\prime}_{j,i} ,\;T} \right)$ or $r^{\prime}_{k,j} = H\left( {z_{k,j} ,\;V^{\prime}_{j,i} ,\;T} \right)$ and checks whether $h^{\prime}_{k,j} \equiv h_{k,j}$ or $r^{\prime}_{k,j} \equiv r_{k,j}$ holds or not. It is obvious that if these equations holds, an adversary should be able to compute $w_{k,j} = \left( {T_{k} } \right)^{{x_{j} }} \;\bmod \;q$ or $z_{k,j} = \left( {\Gamma _{j} } \right)^{{t_{k} }} \;\bmod \;q$. However, it is well known that a problem of finding $w_{k,j}$ or $z_{k,j}$ values is computationally hard, i.e., to obtain these values we need to solve DL problem for the equations $y_{j} = g^{{x_{j} }} \;\bmod \;p$ and $T_{k} = g^{{t_{k} }} \;\bmod \;p$ or $\Gamma _{j} = g^{{\alpha_{j} }} \bmod \;p$.

In the second method of attacks, a malicious participant U_i broadcasts the message V_i,j = ‘Step4: failure’ or V_i,j = ‘Step5:failure’ to claim that U_j is a malicious participant, while U_j is actually an honest participant. In such case, U_j resends message tM_j (for Step 4) or M_j and (α_j, a_j, K_j) (for Step 5) to prove his honesty. Next, other honest participants validate message tM_j by checking $g^{{tCert_{j} }} \equiv T_{j} \left( {V_{j} \left( {y_{j} } \right)^{{h_{j} }} } \right)^{{g_{j} }} \,\left( {mod\,p} \right)$ (see point (a) of Step 6) or messages M_j and (α_j, a_j, K_j) according to the point (b) of Step 6.

The information about any malicious attempt of U_i or an adversary A who eavesdrops on the broadcast channel and tries to alter the exchanged messages in Step 4 or Step 5, is placed in V_j,i element of the verification matrix, for all 1 ≤ j ≤ n, j ≠ i. On receiving such fault messages, all honest participants start the fault detection phase and decide that U_i is indeed malicious participant. As a result, a participant U_i will be proved to be the malicious participant and then be removed from the set of honest participants.

Now, consider second condition (ii). Since in this case, where any honest participants U_i and U_j follow the protocol and broadcast valid messages, all participants can properly compute the same sub-key K_i. This is truth even if a malicious participant U_m sends out the failure message to convince other honest participants that U_i and U_j are dishonest or if an adversary A intercepts the message $V_{i,j}$ = ‘Step4:success’ or $V_{i,j}$ = ‘Step5:success’ sent from U_i and changes it to $V_{i,j}$ = ‘Step4: failure’ or $V_{i,j}$ = ‘Step5: failure’. It can be noticed, that as above, these attacks are detected in fault detection phase.

Because these two conditions hold, our FF-ACKA protocol satisfies the fault-tolerance property. The last security property in this section is the forward secrecy. Below, we demonstrate that the proposed protocol has the forward secrecy property. Forward secrecy should protect the previously established conference keys and all its components against compromises, even if the long-term private key is compromised.

Theorem 2

(Forward Secrecy, [17]) If solving the discrete logarithm problem is computationally infeasible, the FF-CKAP provides forward secrecy.

Proof.

The proof of Lemma 2 is similar to the proof of [17]. Suppose that adversary A compromises at time (τ + 1) the long-term private key $x_{i}$ of any participant U_i and can obtain the conference key K at time τ, where K is composed of all participants’ sub-keys K_i (1 ≤ i ≤ n). Because each K_i is distributed to other participants U_j (1 ≤ j ≤ n, j ≠ i) using their temporary public keys $T_{j} = g^{{t_{j} }} \;\bmod \,p$, an adversary A should be able to obtain the short-term private key $t_{j}$. The adversary can try to get t_j directly from $T_{j} = g^{{t_{j} }} \;\bmod \,p$ or indirectly either form $tCert_{j} = \left( {t_{j} + \left( {v_{j} + x_{j} h_{j} } \right)\,g_{j} } \right)$ mod q or $\sigma_{j} = \left( {\alpha_{j} + \left( {\beta_{j} + t_{j} c_{j} } \right)\;d_{j} } \right)$ mod q (see respective Eq. (1) and Eq. (4)). For the first case, it is obvious that the calculation of $t_{j}$ is equivalent to solving the discrete logarithm problem. However, DL problem is nevertheless considered to be computationally hard. For the second case, even if the adversary knows $x_{j}$, the solving of $tCert_{j} = \left( {t_{j} + \left( {v_{j} + x_{j} h_{j} } \right)\,g_{j} } \right)$ mod q to obtain $t_{j}$ is also discrete problem [20]. In the last case, the adversary with U_j’s secret key $x_{j}$ tries to recover $t_{j}$ form ($T_{j}$,$\Gamma _{j}$,$B_{j}$,$\sigma_{j}$), where $\Gamma _{i} = g^{{\alpha_{i} }} \bmod p$, ${\rm B}_{i} = g^{{\beta_{i} }} \bmod p$ and $\sigma_{j} = \left( {\alpha_{j} + \left( {\beta_{j} + t_{j} c_{j} } \right)\;d_{j} } \right)$ mod q. The value $\sigma_{j}$ (like $tCert_{j}$) is short signature computed using a signature scheme considered in [20]. According to Theorem 1 in [20] this signature scheme is existentially unforgeable under a chosen message attack in the random oracle model, assuming that DL problem is believed to be computationally hard. As a result, the proposed protocol FF-CKAP satisfies the forward secrecy under the difficulty of computing the discrete logarithm problem.

5 Conclusion

In this paper, we proposed an improved authenticated conference-key agreement protocol (FF-ACKA) for a static set of participants. The protocol provides important security properties like forward secrecy and fault-tolerance. Due to the last properties it is possible to ensure that all participants can obtain the same conference key. The proposed protocol uses only two rounds to generate a conference key and enables the efficient detection and elimination of malicious participants from the set of honest participants. Nevertheless, the size of messages exchanged during protocol is proportional to the number of participants.

The FF-ACKA protocol was developed to meet requirements that emerged while we have been developing MobInfoSec project [23–27]. We have needed an authenticated conference channel between mobile devices. We have achieved such channel using several one-to-one channels with a chairman. Such solution was working, but it was not scalable and generated some efficiency and security issues related to the service implementing a chairman role. The FF-ACKA protocol is designed to solve that two problems: to improve overall speed and to improve security by eliminating the necessity to have trust service that plays a chairman role. Preliminary analysis has shown that our protocol should have similar efficiency or in some situations should be faster than protocols proposed by [1, 2, 16, 22]. We are planning to implement the protocol during our future works and test it in several practical scenarios.