Cong GUO et al. Scalable protocol for cross-domain group password-based authenticated key exchange 159
4) Assuming that any step of protocol P
has not aborted,
then each instance will compute a common session key,
as in P.
2.3 Four-Party PAKE protocol
Recently, Chen et al. [15] revisited the problem of cross-
domain secure communication between two participants
from two different domains. They proposed three four-party
password-based authenticated key exchange (4PAKE) pro-
tocols, they show how to build a 4PAKE protocol from a
2PAKE protocol.
Before beginning the protocol, each server generates its
own long-term public/private key pairs and has knowledge of
the other servers’ public keys.
The framework of 4PAKE protocol is divided into the fol-
lowing steps:
• Initialization (M1, M2) Two participants who are from
the different domains intend to establish a session key. They
first exchange their identifiers and ephemeral public keys, re-
spectively.
• Local authentication and key exchange (M3) Each
participant runs a 2PAKE protocol with their local domain
server, and separately establishes a common session key with
their server, that can subsequently be used in the later steps
of this protocol.
• Signature (M4, M5) Each server uses the messages in-
cluding identifiers and ephemeral public key pairs, that are
sent from their local participant and protected by message au-
thentication code (MAC) tags μ, to compute a signature using
the server’s private key. Meanwhile, they send the other do-
main’s public key to their local participant.
• Two-party authentication and key exchange (M6) Par-
ticipants perform asymmetric-key based authenticated key
exchange using information they now have.
3 Cross-domain group password-based au-
thenticated key exchange protocol
We extend Chen’s work [15] to a group setting. Our scheme
can be used in a cross-domain group communication. Princi-
pals use their identities, a nonce, and other domains’ public
keys to agree on a cross-domain group shared session key
without using a trusted certificate authority (CA).
3.1 Notations
First, we define some notations used in our scheme. As-
sume that there exist j ( j = 1, 2,...,m
i
) participants in
each domain D
i
(i = 1, 2,...,n). Let U
i
j
(i = 1, 2,...,n;
j = 1, 2,...,m
i
) denotes the participant, who intends to es-
tablish a common session key with intra-domain and cross-
domain participants. SK
U
i
j
denotes the private key of each
participant U
i
j
in the intra-domain phase. PK
U
i
j
denotes the
public key of each participant U
i
j
in the intra-domain phase.
K
i
denotes the group shared session key in the intra-domain
phase. S
i
denotes the server of each domain D
i
.(pk
S
i
, sk
S
i
)
denotes the public/private key pairs of each authentication
server S
i
in the cross-domain phase. Header H
i
denotes the
concatenated identities of all the participants in each domain
(e.g., H
1
= U
1
1
|U
1
2
|···|U
1
m
1
). Every header has access to
gain the shared session key K
i
which is communicated with
their intra-domain members. X ∈{U
i
j
, S
i
} denotes the enti-
ties in the proposed protocol. ssk
X
1
,X
2
denotes the session key
shared between X
1
and X
2
. Password pw
H
i
,S
i
is a string cho-
sen from a relatively small dictionary to be easily memorized
and typed-in by a human, which is shared between a header
and an authentication server beforehand. k denotes the final
cross-domain group session key.
3.2 The specification of MCGPAKE protocol
Here, with the example of BD protocol, our MCGPAKE pro-
tocol is shown as follows. Our proposed protocol has the fol-
lowing three phases.
3.2.1 Intra-domain group key exchange phase
We introduce a scalable complier for the intra-domain group
key exchange protocol and use BD protocol [16] as an illus-
trative example. Let P = {U
i
j
} denotes the set of participants
U
i
j
, who intend to establish a group session key in each do-
main D
i
. We denote each instance i of participant U
i
j
as Π
i
U
.
A given instance may be used only once. Each instance Π
i
U
has associated with it the variables acc
i
U
,pid
i
U
,andsid
i
U
.The
variable acc
i
U
takes Boolean values indicating whether the in-
stance has been accepted. pid
i
U
, the partner ID of instance
Π
i
U
, is a set containing the identities of the participants in
the group with whom Π
i
U
intends to establish a session key.
Session ID sid
i
U
provides a means of determining which in-
stances are taking part in a given execution of the protocol.
Without loss of generality, we assume that in the original BD
protocol P each message sent by an instance Π
i
U
includes the
sender’s identity U as well as a sequence number that be-
gins at 1 and is incremented each time Π
i
U
sends a message
(e.g., the jth message sent by an instance Π
i
U
has the form
U | j | m).
Let Σ=(Gen,Sign,Vrfy) be a signature scheme that is