A Batch-Authenticated and Key Agreement
Framework for P2P-Based Online Social Networks
Lo-Yao Yeh, Member, IEEE, Yu-Lun Huang, Member, IEEE, Anthony D. Joseph, Member, IEEE,
Shiuhpyng Winston Shieh, Senior Member, IEEE, and Woei-Jiunn Tsaur, Member, IEEE
Abstract—Online social networks (OSNs) such as Facebook and
MySpace are flourishing because more and more people are using OSNs to share their interests with friends. Because security and privacy issues on OSNs are major concerns, we propose a security framework for simultaneously authenticating multiple users to improve the efficiency and security of peer-to-peer (P2P)-based OSNs. In the proposed framework, three batch authentication protocols are proposed, adopting the one-way hash function, ElGamal proxy encryption, and certificates as the underlying cryptosystems. The hash-based authentication protocol requires lower computational cost and is suitable for resource-limited de-vices. The proxy-based protocol is based on asymmetric encryp-tion and can be used to exchange more informaencryp-tion among users. The certificate-based protocol guarantees nonrepudiation of trans-actions by signatures. Without a centralized authentication server, the proposed framework can therefore facilitate the extension of an OSN with batched verifications. In this paper, we formally prove that the proposed batch authentication protocols are secure against both passive adversaries and impersonator attacks, can offer implicit key authentication, and require fewer messages to authenticate multiple users. We also show that our protocols can meet important security requirements, including mutual authen-tication, reputation, community authenticity, nonrepudiation, and flexibility. With these effective security features, our framework is appropriate for use in P2P-based OSNs.
Index Terms—Authentication protocol, batch authentication,
Online social networks (OSNs), Peer to peer (P2P).
Manuscript received May 20, 2011; revised October 14, 2011 and December 5, 2011; accepted February 2, 2012. Date of publication February 23, 2012; date of current version May 9, 2012. This work was supported in part by the Team for Research in Ubiquitous Secure Technology Center, University of California, Berkeley, the National Science Council under Grant NSC 100-2218-E-492-026 and Grant NSC 100-2219-E-212-001, the Networked Communica-tions Program, the Industrial Technology Research Institute, the Institute for Information Industry, the Chung Shan Institute of Science and Technology, Chunghwa Telecomm., Bureau of Investigation, D-Link, the International Collaboration for Advancing Security Technology, and the Taiwan Information Security Center, Ministry of Education, Taiwan. The review of this paper was coordinated by Prof. J. Misic.
L.-Y. Yeh is with the Network and Information Security Division, National Center for High-Performance Computing, Hsinchu 30076, Taiwan, and also with the Department of Information Management, National Chi Nan University, Nantou 545, Taiwan (e-mail: [email protected]).
Y.-L. Huang is with the Department of Electrical and Control Engineering, National Chiao-Tung University, Hsinchu 300, Taiwan.
A. D. Joseph is with the Department of Electrical Engineering and Computer Sciences, University of California at Berkeley, Berkeley, CA 94720 USA.
S. W. Shieh is with Department of Computer Science, National Chiao Tung University, Hsinchu 300, Taiwan.
W.-J. Tsaur (Corresponding author) is with the Department of Informa-tion Management, Da-Yeh University, Changhua 51591, Taiwan (e-mail: [email protected]).
Color versions of one or more of the figures in this paper are available online at http://ieeexplore.ieee.org.
Digital Object Identifier 10.1109/TVT.2012.2188821
I. INTRODUCTION
O
NLINE social networks (OSNs) such as Facebook,MySpace, and Twitter are increasingly popular services. People can share information and pictures with old acquain-tances, as well as relationships with friends. It is estimated that half a billion registered users interact with friends over OSNs [1], [2]. However, the weak authentication and registration process of current OSNs may lead to some security attacks [3]. With the rapid growth of OSNs, more valuable information is stored on OSNs. Hence, the privacy and security issues inherent to OSNs have attracted much attention.
Peer-to-peer (P2P) technology is considered in the design of next-generation OSNs. As described in [6], a P2P-based OSN consists of the following three levels: 1) the social network level represents members and their relationships; 2) the application service level implements the P2P-based application infrastruc-ture; and 3) the communication and transport level provides transport services over networks such as the Internet or mobile ad hoc networks. Relying on the cooperation between a number of independent parties who are also OSN users, a decentralized P2P architecture can be adopted with merits, including strong privacy protection, better scalability, and a lowered requirement for continuous Internet connectivity [1], [4]. Furthermore, a P2P architecture can take advantage of real social networks and geographic proximity to support local services.1
P2P-based OSNs is a relatively new trend. Only a few studies [3], [5] have designed their security protocols based on the P2P architecture. In 2009, Buchegger et al. [5] examined the feasibility of P2P-based OSNs and advocated the use of en-cryption techniques to ensure privacy issues. In [6], the authors described a decentralized and privacy-preserving OSN appli-cation called Safebook, but no specific protocol was defined. Ge et al. [3] proposed a message delivery scheme (VisualSec) based on a fully distributed method that attempts to provide authentication and key generation services. However, identity authentication was not fully addressed, and only the out-of-band (OOB) authentication method is mentioned in VisualSec. Another alternative is to integrate the existing authentication protocols from P2P networks into the P2P-based OSNs. In 2003, Shardul et al. [8] divided P2P users into several groups (called troupes). Taking zero knowledge and CLIQUES as bases, each troupe required a central computing authority for authentication. Lee and Kim [9] also proposed an adaptive 1This paper focuses only on the security issues of P2P-based OSNs and not other challenging problems of P2P networks such as global search and content distribution [7].
authentication protocol based on the reputation of P2P systems. The reputation of each peer affects the type of certificates to be used in authenticating a user. In 2006, Nguyen [10] adopted identity-based cryptography and preshare keys to design a simplified P2P device authentication protocol. However, these existing protocols suffer from the following weaknesses.
1) Most of the current security protocols [1], [5], [6] for P2P-based OSNs lack specific procedures.
2) In current security protocols for P2P-based OSNs, each user has to be authenticated by OOB methods, which may impede the extension speed of social networks.
3) Most of the existing protocols support only one-to-one authentication.
4) The existing protocols do not consider the restrictions of underlying devices such as computing power and mem-ory limitations.
This paper proposes a framework to take advantage of the P2P architecture, including geographic proximity. Under the proposed framework, three batch authentication protocols are designed, using different cryptographic primitives, for different devices in P2P-based OSNs. The novel contributions of this paper are listed as follows.
• The proposed framework reduces the communication cost required for authenticating users.
• Due to their different security properties, the proposed protocols can be realized on a variety of devices such as personal digital assistants (PDAs), mobile phones, and laptops.
• By incorporating different trust levels, the proposed pro-tocols allow a user with a high trust level to help authen-ticate other users and achieve the extensibility of a social network.
• The proposed protocols support a one-to-many authen-tication, which is the basis of batch authenauthen-tication, to simultaneously authenticate multiple users. To the best of our knowledge, this paper is the first study that offers one-to-many batch authentication in P2P-based OSNs. The proposed protocols are proved to be capable of mutually authenticating communication peers and remain secure against passive adversaries.
This paper is organized as follows. We briefly introduce the cryptographic background in Section II. Section III presents the assumptions and notations used in the proposed proto-cols. The details of the proposed protocols are described in Section IV. Then, we give the proof of security analysis and a performance comparison in Sections V-B and VI, respectively. Finally, this paper is concluded in Section VII.
II. ELGAMALPROXYENCRYPTION
By applying proxy encryption, a ciphertext C that is en-crypted by one user is transformed to ˆC, which is decrypted
by another user. In 2007, Huang et al. [12] realized proxy encryption using an ElGamal cryptosystem. In the ElGamal cryptosystem, two public parameters p and q are shared by all users, where p is a prime that is equal to 2q + 1, and g is the generator inZ∗p.
Then, a sender UA randomly chooses a secret key x inZ∗p and makes β = gxas his/her public key. U
A generates two ci-pher values (C1, C2), where C1= grmod p, C2A = ξ(β
r) =
ξ((gx)r) mod p, r∈ Z∗
q is a randomly selected number, and
ξ represents the message. Assuming that the receiver UB pos-sesses his/her secret key y and the proxy UP holds the trans-formation key (y− x), the sender UA sends the cipher value (C1, C2A) to UP, and the proxy UP implements the following
two tasks:
• transforms the cipher value C2Ainto C2P= C2A·C
(y−x)
1 ;
• sends (C1, C2P) to the receiver UB.
Upon receipt of (C1, C2P), UB decrypts the cipher with
his/her secret key y and derives the message ξ.
The proxy UPnot only alters the cipher (C1, C2A) but also
dis-tributes a tailor-made component to UB. When adopting such an encryption method to our protocols, a minor modification is required for authenticating multiple users in one verification procedure. In our protocols, the proxy distributes the tailor-made parameters to each peer, and the authentication requester relies on these parameters to decrypt the cipher, cooperatively made by authenticating peers. If the message contents are received and verified, these peers are considered authenticated.
III. BATCHAUTHENTICATIONFRAMEWORK
A. Background
In P2P-based OSNs, each user may act as a client or a server. Based on the uniqueness of such characteristics, we propose three novel protocols for authenticating P2P-based OSN users in batch. In the proposed protocols, a user can simultaneously authenticate several users through a trusted friend.
With regard to the authentication of the trusted friend, similar to [1], [5], and [6], the OOB method is assumed in our pro-tocols. For example, a face-to-face preauthentication method [11], [13] through a location-limited channel can be used for negotiating a shared secret key between two friends. Once a user (e.g., UX) is authenticated by another user (UR), UX becomes a friend of URand further helps URto scale up his/her social network. Note that the proposed protocols are different from other group key management protocols [15] due to the following reasons.
1) Different goals. In conventional group key management protocols, a group is formed for a temporary purpose. The group is dismissed when that temporary purpose is served, and then, the group members lose relation-ships with other group members. Our social-based batch authentication protocols are designed for authenticating friends in OSNs. Once a group member is authenticated, he/she can help friends for another batch authentication. Such authentication protocols help extend the social net-work of a user.
2) Different behaviors. In most group key management pro-tocols, group members are authenticated by the group leader “one by one.” That is, n authentication mes-sages are required to authenticate n group members. Then, these members share one common group key for the group communication. In our batch authentication
Fig. 1. Scenario of a batch authentication protocol.
protocols, users are simultaneously authenticated by the requester. That is, one authentication message is required to authenticate n session peers. Then, the requester nego-tiates one secret key with each user instead of sharing one group key among all users.
In Fig. 1, for example, assume that Alice and Bob have performed a face-to-face preauthentication through a location-limited channel (e.g., in a conference) in advance. They exchanged a secret shared key and shared friends lists, trust levels, and social relationships with each other after the preauthentication.
If Alice (who acts as the UR) wants to communicate with users John, Tom, and Mary from Bob’s friends list, she can ask Bob (who behaves as the UA) to help the authentication. After successful authentication, Alice can exchange shared keys with John, Tom, and Mary and can add them into her friends list to broaden her social network.
B. Requirements and Notations
To support devices with different computing power, we pro-pose three batch authentication protocols that adopt hash func-tion, proxy encrypfunc-tion, and certification [16] as their underlying cryptography methods. The hash-based batch authentication protocol adopts a lightweight hash function and is suitable for resource-limited devices such as PDAs and cell phones. For devices with stronger computing power, the proxy-based batch authentication protocol can be applied to ensure confidentiality. The certificate-based batch authentication protocol can be used to protect sensitive and nonrepudiation transactions. These batch authentication protocols are explained in Section IV.
Considering the features of OSNs [1], [5], [6] and P2P archi-tecture [9], we summarize the requirements of an authentication protocol for P2P-based OSNs as follows.
R1: Strong authentication. Mutual authentication should be guaranteed to guard against possible attacks.
R2: Reputation. Reputation ensures accountability in P2P-based OSNs.
R3: Community authenticity. Each user should efficiently verify the source of messages. For example, a session key can be established with the use of keyed message authentication code.
R4: Nonrepudiation. Nonrepudiation must be guaranteed so that dispute for an invalid commercial transaction can be settled by a court.
R5: Flexibility. An authentication protocol should be adopted into any OSN, either web- or P2P-based networks.
R6: Batch authentication. Because a user may be far away from other users in a P2P network, authenticating mul-tiple users in one transaction may reduce the communi-cation cost.
R7: Comprehensive hardware support. An authentication protocol should support a variety of devices with dif-ferent computing powers.
The notations used throughout this paper are listed in Table I.
C. Sketch of the Proposed Batch Authentication
The proposed batch authentication protocols, which are com-posed of three roles, a requester UR, an authenticator UA, and a user group ˆU, are operated based on the following assumptions.
1) The requester URand authenticator UAhave negotiated a shared key by face-to-face preauthentication through a location-limited channel [11], [13].
2) The authenticator UAis trusted by all his/her friends who are involved in the batch authentication.
3) If two users UX and UY are friends, they have shared a secret key KXY.
In the proposed protocol, UAhelps URauthenticate the user group ˆU , in which all users are friends of UA. After successful authentication, UR establishes a shared key KRi with each user Ui in the group (Ui∈ ˆU ). We briefly explain our design concept by the following two cases. The detailed explanations of each message are introduced in Section IV.
In the first case, we introduce a user group with only one user U1( ˆU ={U1}), as shown in Fig. 2(a). The message flow
is given as follows. 1) UR→ UA: AQR,A. 2) UA→ U1: CRA,1. 3) U1→ UR: CR1,R.
4) UR→ U1: M RR,1.
The requester URinitiates a request to the authenticator UA. Then, UA helps contribute some parameters to UR and U1 at
Steps 2 and 3. Finally, URreplies a message (M RR,1) at Step 4 for mutual authentication.
The second case scales up the user group to n users ( ˆU = {U1, U2, . . . , Un}, and | ˆU| = n),2 as shown in Fig. 2(b). The message flow is given as follows.
1) UR→ UA: AQR,A. 2) UA→ U1: CRA,1.
3) Ui−1→ Ui: CRi−1,i, where 2≤ i ≤ | ˆU|. 4) U| ˆU|→ UR: CR| ˆU|,R.
5) UR→ Ui: M RR,i, where 1≤ i ≤ | ˆU|.
2We assume that the n users are online in the course of the batch verification or the batch authentication will fail. Note that the assumption can hold if UA can inform the users in ˆU before the batch verification is executed.
TABLE I
PARAMETERS ANDNOTATIONS
Fig. 2. Message flows of batch authentication for (a) only one member and (b) several members in case n = 3.
Similarly, UR sends a request to UA. The authentica-tion requests (chain reply CRi,i+1) are then passed through
U1, U2, . . . to Unat Steps 2 and 3∗. At Step 4, U| ˆU|sends back the chain reply to UR. For mutual authentication, UR sends
M RR,ito users Ui∈ ˆU .
IV. PROPOSEDPROTOCOLS
This section explains the proposed batch protocols with different underlying cryptographic functions, including hash, proxy encryption, and certificates. Considering the security and performance issues, we recommend the proxy-based protocol as the default protocol in general situations.
A. Hash-Based Protocol
The hash-based batch authentication protocol, with the fol-lowing message flow, is illustrated in Fig. 3.
1) UR→ UA: AQR,A={IDR, KRA⊕ NR, U ID⊕ H(r, (NR+ 1)), KPR⊕ H(r, (NR+ 2)), M ACR}. 2) UA→ U1: CRA,1 ={X, MACA}. 3) Ui−1→ Ui : CRi−1,i={Mi, X, KPUˆ, M ACi}, where 2≤ i ≤ | ˆU|. 4) U| ˆU|→ UR: CR| ˆU|,R={M| ˆU|, X, KPUˆ, M AC| ˆU|}. 5) UR→ Ui: M RR,i={Y, MACR }, where 1 ≤ i ≤ | ˆU|.
Fig. 4. Proposed one-way hash chain.
The hash-based batch authentication protocol is detailed as follows.
Step 1) UR sends AQR,A to UA. AQR,A is composed of UR’s identification (IDR), a nonce (NR), the user group identification (U ID ={ID1, ID2, . . . , ID| ˆU|}), and the parameters of key agreement
(KPR={gm1, gm2, . . . , gm| ˆU|}, where mi∈ Zp∗). The nonce is protected by a secret key KRA that is shared by UR and UA. The group identification and key parameters are protected by the nonce. In addition, a message authentication code M ACR=
H(IDR,{KRA⊕NR}, UID⊕H(r, (NR+1)),
KPR⊕ H(r, (NR+ 2)), (NR+ 3)) is attended to ensure the integrity of message.
Step 2) Upon the receipt of AQR,A, UA derives NR by performing KRA⊕ {KRA⊕ NR} and checks the validity of M ACR. If AQR,Ais correct, the follow-ing steps are implemented.
• UArandomly generates an initial value h0and
a sequence of random numbers wi(for 0≤ i ≤
| ˆU| − 1). Then, UAconstructs and maintains a chain of one-way hash values (hi= H(hi−1⊕
wi−1) for 1≤ i ≤ | ˆU|), as shown in Fig. 4. • UAderives the user group identification U ID
and the key parameters KPRby NR. • UAcomputes V0for UR, where
V0= IDA, H (r, (KRAt0)) ⊕ h0H(KRA)NA | ˆU|−1 ∪ j=0 wj , t0 .
Note that the unequal-bit-length problem can be solved by the specific length extension hash function
H(r, msg) and V0 should be regarded as a single
element from the view of calculation. As mentioned in the previous section, KRA is the shared key between UR and UA, NA and t0 are random
chal-lenges from UA, and∪| ˆj=0U|−1wjis a concatenation of
w0, w1, . . . , w| ˆU|−1.
• UA also computes Vi for Ui∈ U, (1 ≤ i ≤
| ˆU|), where Vi ={IDA, H (r, (KAiti))
⊕ (hiH(KAi)NR+ NAgmi) , ti} . In Vi (i = 0), gmi is used for negotiating session keys KRi between UR and Ui in the end of the batch authentication.
• To eliminate the bandwidth requirements, we adopt the Chinese reminder theory (CRT) [17] to accommodate messages in a single message. Let B0, B1, B2, . . . , B| ˆU| be | ˆU| + 1 positive
integers that are pairwise relative primes and
A0, A1, A2, . . . , A| ˆU| be the multiplicative
in-verses of B0, B1, B2, . . . , B| ˆU|. UAcomputes a common solution X for the following congru-ous equations: X≡ V0mod B0(for UR) X≡ Vimod Bi for Ui∈ U, 1 ≤ i ≤ | ˆU| .
By the CRT, we have X = (| ˆi=0U| L/Bi×
Vi× Ai) mod L, where L = | ˆU| i=0 Bi Ai× (L/Bi) mod Bi ≡ 1. • UA calculates M ACA= H(X, NR+ NA) and sends the chain reply CRA,1 ={X,
M ACA} to the first user in the group (U1).
Step 3) After receiving CRA,1={X, MACA}, the follow-ing steps are implemented.
• U1 retrieves V1 by calculating X mod B1.
Next, U1 obtains H(r, (KA1t1))⊕ (h1 H(KA1)NR+ NAgm1) and t1from V1. U1
then uses the shared keys KA1and t1to derive hi, H(KA1), NR+ NA, and gm1.
• The validity of V1 and CRA,1 can be ver-ified by H(KA1) and M ACA, respectively. The request is dropped when any invalidity is detected. Then, U1computes M1= H((NR+
NA)⊕ h1) and adds a key parameter gn1 to KPUˆ.
• U1 generates M AC1= H(M1, X, KPUˆ,
(NR+NA)) and sends message CR1,2={M1, X, KPUˆ, M AC1} to the next group user U2.
For Ui∈ U(2 < i ≤ | ˆU|), the following steps re-peat until the chain reply passes through all group users.
• Ui gets CRi−1,i={Mi−1, X, KPUˆ, M ACi−1} from Ui−1. Ui extracts Vi by
X mod Bi. Similarly, Ui can obtain hi,
H(KAi), NR+ NA, gmi from Vi by the shared key KAiand random challenge ti. • The validity of Vi and CRi−1,i can be
ver-ified by H(KAi) and M ACi−1, respectively. When any invalidity is detected, the request is dropped, and Uireports the failure to UA. Then,
Ui computes Mi= Mi−1⊕ H((NR+ NA)⊕
hi) and adds a key parameter gni to KPUˆ.
• Uigenerates M ACi= H(Mi, X, KPUˆ, (NR+
NA)) and sends CRi,i+1={Mi, X, KPUˆ, M ACi} to the next group user Ui+1.
Step 4) Upon the receipt of the last chain reply CR| ˆU|,R =
{M| ˆU|, X, KPUˆ, M AC| ˆU|}, the following steps are
implemented.
• URcomputes X and B0and obtains V0. With
the shared key KRAand random challenge t0, UR derives h0, H(KRA), NA, and ∪| ˆj=0U|−1wj from V0.
• Similarly, the authenticity of V0 and M AC| ˆU| can be verified by H(KRA) and M AC| ˆU|. If validated, UR derives hi (1≤ i ≤ | ˆU|) by h0
and∪| ˆj=0U|−1wj.
• UR also computes M| ˆU|= H((NR+ NA)⊕
h1)⊕ H((NR+ NA)⊕ h2)⊕ · · · ⊕ H((NR+
NA)⊕ h| ˆU|) and compares it with M| ˆU|. If matched, the user group ˆU is authenticated.
Otherwise, at lease one of the users fails the authentication, and the session terminates. • After the successful batch authentication, UR
computes session keys SKRi= (gni)mi for
Ui(1≤ i ≤ | ˆU|).
• For mutual authentication, UR calculates replies Si= H((NR+ NA+ 1)⊕ hi) mod
Bi. Again, by applying the CRT [17], we can find a common solution for
Y ≡ S1mod B1 Y ≡ S2mod B2
.. .
Y ≡ S| ˆU|mod B| ˆU|.
Then, UR generates M ACR = H(Y, (NR+
NA)) and sends M RR,i={Y, MACR } to
Ui (1≤ i ≤ | ˆU|). In the case that UR cannot directly reach Ui, UA can be involved to help forward the messages.
Step 5) After receiving M RR,i from UR (or Ui−1), the following steps are implemented.
• Uifirst checks the validity of M ACR .
• The session is dropped if M ACR fails the check; otherwise, Ui computes Si= Y mod
Bi and checks the equality of Si, where Si=
H((NR+ NA+ 1)⊕ hi) (1≤ i ≤ | ˆU|). If the equality holds, UR is authenticated; other-wise the session is terminated.
• After the successful batch authentication, Ui computes the session key SKRi= (gmi)ni. Subsequent communications between UR and
Uican be protected by SKRi.
B. Proxy-Based Protocol
By using the ElGamal proxy encryption scheme [12], the proxy-based protocol can carry trust levels [9] for entities that are involved in the batch authentication. In this protocol, we set two public parameters, p and g, where p is a prime of the form 2q + 1, and g is a generator inZ∗p. Similar to the
hash-based protocol, the proxy-hash-based batch authentication protocol comprises the following five messages, as illustrated in Fig. 5.
1) UR→ UA: AQR,A= {IDR,{C1, C2R}, KRA⊕ NR, U ID⊕ H(r, (NR+ 1)), M ACR}. 2) UA→ U1: CRA,1={C1, C2A, X, M ACA}. 3) Ui−1→ Ui: CRi−1,i={C1, C2i, X, KPUˆ, M ACi}, where 2≤ i ≤ | ˆU|. 4) U| ˆU|→UR: CR| ˆU|,R={C1, C2| ˆU|, X, KPUˆ, M AC| ˆU|}.
5) UR→ Ui: M RR,i={C2, M ACR }, where 1≤i≤| ˆU|. Step 1) The requester UR sets the shared key KRA as the seed of the ElGamal proxy encryption key and then starts the batch authentication protocol as follows.
• UR sends the authentication request AQR,A=
{IDR,{C1, C2R}, KRA⊕ NR, U ID⊕ H(r, (NR+ 1)), M ACR} to UA.
Step 2) Upon the receipt of AQR,A, the following steps are implemented.
• UAfirst derives NRby the shared key KRAand extracts the U ID by NR.
• Next, UAverifies M ACRand checks whether each Ui’s trust level that is maintained by him-self is higher than the predefined trust thresh-old. If one of the verifications fail, UA drops this session. Otherwise, UA computes V0 for URand Vifor Ui∈ U as V0= IDA, EKRA NA, | ˆU| j=1 KAj, H(KRA) Vi= IDA, EKAi KRA+NR+NA+ ˆ |U| j=1 j=i KAj, H(KAi) . • Similarly, by applying the CRT [17], we can accommodate all replies in a single message as
X ≡ V0mod B0(for UR)
X ≡ V1mod B1(for U1)
.. .
X ≡ Vimod Bi(for Ui∈ U).
As mentioned in Section IV-A, by the CRT, we obtain X = (| ˆi=0U| L/Bi∗ Vi∗ Ai) mod L. • Based on the ElGamal proxy encryption
scheme, UAcalculates C2A= (C2R× C1NR) mod p = ξβr× gr(NR) mod p = ξg(KRA)r× gr(NR) mod p = ξgr(KRA+NR) mod p .
– UA generates the message authentica-tion code to protect the integrity of the message, where MACA= H(C1, C2A,
X, (KRA+NR+NA+ | ˆU|
• UA sends CRA,1={C1, C2A, X, M ACA} to U1.
Step 3) After receiving CRA,1, the following steps are im-plemented.
• U1 extracts V1= X mod B1 and decrypts EKAi(KRA + NR + NA +
| ˆU| j=2KAj,
H(KA1)) by KA1.
• U1 verifies the integrity of V1 and CRA,1 by checking H(KA1) and M ACA, respectively. The request is dropped when any invalidity is detected. • U1calculates C21= C2A× C1(KA1) mod p = ξgr(KRA+NR)× gr(KA1) mod p = ξgr(KRA+NR+KA1) mod p .
• U1 selects the parameter of the session key KPUˆ ={gn1}.
• Because KA1is shared with UAand U1, only
legitimate U1 can decrypt V1, add KA1 with
KRA+NR+NA+ | ˆU|
j=2KAj, and compute the message authentication code M AC1= H(C1, C21, X, KPUˆ, KRA + NR+ NA+ | ˆU|
j=1KAj).
• U1 sends CR1,2={C1, C21, X, KPUˆ, M AC1} to U2.
For Ui∈ U (2 < i ≤ | ˆU|), the following steps repeat until the chain reply passes through all group users.
• Upon the receipt of CRi−1,i, Ui derives Vi=
X mod Bi and decrypts EKAi(KRA+ NR+
NA+ | ˆU|
j=i j=1
KAj, H(KAi)) by KAi.
• Ui checks the validity of H(KAi) and
M ACi−1. The session is dropped if any inva-lidity is detected; otherwise, Uicomputes
C2i = C2i−1× C1(KAi) mod p = ξg r KRA+NR+ i−1 j=1 KAj gr(KAi) mod p = ξg r KRA+NR+ i j=1 KAj mod p.
• Ui selects a parameter of session key gni and attaches it to KPUˆ. Then, Ui gener-ates M ACi= H(C1, C2i, X, KPUˆ, KRA+
NR+ NA+ | ˆU|
j=1KAj).
• Ui sends CRi,i+1={C1, C2i, X, KPUˆ, M ACi} to the next user Ui+1.
Step 4) After receiving CR| ˆU|,R, the following steps are implemented.
• UR computes V0= X mod B0 and
decrypts V0 by KRA to obtain
(NA, |U|
j=1KAj, H(KRA)).
• UR checks the validity of V0by H(KRA) and
M AC| ˆU|. If valid, URcomputes ξ= C2|U|ˆ × C1 KRA+NR+ | ˆU| j=1 KAj −1 = ξg r KRA+NR+ | ˆU| j=1 KAj × g r KRA+NR+ | ˆU| j=1 KAj −1 mod p.
• If ξ is identical to ξ, then all the group users
Ui∈ ˆU are authenticated; otherwise, at least one group user fails the batch authentication. • Once ˆU is authenticated, URcan extract the key
parameters of session key gni from KP
ˆ U and negotiate session keys with Ui∈ U. The ses-sion keys can be obtained by SKRi= (gni)mi.
• For mutual authentication and key
agreement, UR computes C2= C2| ˆU|×C1NAmod p and M AC R= H(C2, KRA+ NR+ NA+ | ˆU| j=1KAj). Then, the message {C2, M ACR } is sent to Ui (1≤ i ≤ | ˆU|). In the case that UR cannot directly reach Ui, UA can be involved to help forward the messages.
Step 5) After receiving M RR,ifrom UR, the following steps are implemented.
• Uiverifies the authenticity of M ACR and com-putes ξ= C2× C1 KRA+NR+NA+ | ˆU| j=1 KAj −1 mod p = ξg r KRA+NR+NA+ | ˆU| j=1 KAj × g r KRA+NR+NA+ | ˆU| j=1 KAj −1 mod p.
• Uialso checks whether IDRis included in ξ. If yes, URis authenticated.
Fig. 6. Message flow of the certificate-based batch authentication protocol. The illustration shows an example of a user group of size 3 (| ˆU| = 3).
• Then, Ui generates the session key SKRi = (gmi)nito protect the communication between
URand Ui.
C. Certificate-Based Protocol
The certificate-based protocol is proposed to guarantee the nonrepudiation of a transaction. In this protocol, we adopt the Shamir–Tauman online/offline signature [16] to enhance
the security property. The authenticator UA, behaving as a local trusted certificate authority, helps deliver and verify certificates for the group users (Ui∈ U). The message flow of the proposed certificate-based batch authentication protocol is summarized as follows (see Fig. 6).
1) UR→UA: AQR,A={P KA{IDR, NR,U ID}, MACR}. 2) UA→ UR: ARA,R={P KR{NR+ 1, ˆT}, MACA}. 3) UR→ U1: CRR,1={C1, X, MACA}.
4) Ui−1→ Ui: CRi−1,i = {C1, C2i, X, KPUˆ, M ACi}, where 2≤ i ≤ | ˆU|.
5) U| ˆU|→UR: CR| ˆU|,R={C1, C2| ˆU|, X, KPUˆ, M AC| ˆU|}.
The certificate-based protocol is described through the fol-lowing steps.
Step 1) UR sends AQR,A to UA, where AQR,A=
{P KA{IDR, NR,U ID ={ID1, ID2, . . . , ID| ˆU|}}, M ACR}. In this message, the requester identity
IDR, nonce NR, and user group identification
U ID are protected by UA’s public key (P KA). The message authentication code M ACR is derived by
H(P KA{IDR, NR, U ID}, KRA+ NR) and used to guarantee the validity of the message.
Step 2) When UA receives the AQR,A, the following steps are implemented.
• UA decrypts AQR,A and obtains IDR, NR, and U ID.
• UA checks the validity of M ACR. If illegal,
UAdrops this connection; otherwise, UA con-firms each Ui’s trust level and then encrypts
{NR+ 1, ˆT} by UR’s public key (P KR), where ˆT ={T1, T2, . . . , T|U|}. If any Ui’s trust level is lower than the predefined threshold, UA should note the information to UR.
• UA derives M ACA= H(P KR{NR+ 1, ˆT},
KRA+ NR) to protect the validity of the message.
• UA sends ARA,R to UR, where ARA,R=
{P KR{NR+ 1, ˆT}, MACA}.
Step 3) After obtaining ARA,R, the following steps are implemented.
• UR checks the validity of the message by
M ACA and NR+ 1. If invalid, UR immedi-ately drops the session; otherwise, URdecrypts the message by his/her private key RKR and obtains ˆT . Similar to the proxy-based batch
authentication protocol, UR computes the fol-lowing values:
1) C1 = gr, where r is a randomly selected secret parameter r∈ Z∗q;
2) Vi= C2i, where C2i= ξi(P Ki)r=
ξi(gRKi)r, and ξi={trust level, S, δ =
Sign(RKR, C1), TR, gmi}, where S is a random number used as the seed of the ElGamal proxy encryption key, and δ is a signature generated by the Shamir–Tauman online/offline signature protocol [16].
• In addition, by adopting the CRT [17], we can merge all messages to Ui∈ U in a single message. Letting B1, B2, . . . , B| ˆU| be positive
integers that are pairwise relative primes and
V1, V2, . . . , V|U|be positive integers, we intend to obtain the solution for the following congru-ous equations: X≡ Vimod Bi for Ui∈ U, 1 ≤ i ≤ | ˆU| .
We can derive the common solution X for
X = (| ˆi=1U| L/Bi× Vi× Ai) mod L, where 1≡ Ai× (L/Bi) mod Bi, and {Vi, Bi|i ∈
{1, . . . , | ˆU|}}. Let X = Vimod Bi for 1≤ i ≤ | ˆU|. Then, the common solution X
should be within the range of [1, L− 1], where
L =| ˆi=1U| Bi.
• UR generates M ACR= H(C1, X, S)
and sends the message CRR,1={C1, X,
M ACR} to U1.
Step 4) Upon the receipt of CRR,1, the following steps are implemented.
• U1 extracts V1= X mod B1to obtain C21= ξ1(P K1)r= ξ1(gRK1)r.
• U1 decrypts C21 by his/her own private key RK1and obtains ξ1, where
C21(C1RK1)−1 mod p =ξ1(P K1)r(C1RK1)−1mod p
=ξ1(gRK1)r
(gr)RK1−1mod p
=ξ1={trust level, S, δ, TR, gm1}. • U1derives S from ξ1and checks the validity of
M ACR. The session is dropped if M ACR is invalidated; otherwise, U1 continues to verify
the signature δ that is signed by UR. UR is authenticated if the signature is valid.
• If UR is authenticated, U1 selects a random
number n1, generates the parameter of session
key gn1, and adds the parameter to KP
ˆ U =
{gn1}. Note that U
1can now obtain the session
key SKR1= (gm1)n1 and use it to protect the session.
• U1 generates C21= ξ(P KR)S+1=
ξ(gRKR)S+1, where ξ={ID
R}.
• U1 appends the authentication message
code M AC1= H(C1, C21, X, KPUˆ, S) to
the message CR1,2={C1, C21, X, KPUˆ, M AC1} and sends the message to U2.
For Ui∈ U (2 < i ≤ | ˆU|), the following steps repeat until the chain reply passes through all group users.
• After receiving the CRi−1,i={C1, C2i−1,
X, KPUˆ, M ACi−1}
1) Ui derives Vi = X mod Bi to obtain
C2i= ξi(P Ki)r= ξi(gRKi)r.
2) Ui decrypts C2i by his/her private key
RKi and checks the validity of M ACi−1 and δ (UR’s signature).
3) If URis legitimate, Uiadds the parameter
gni to KP
ˆ
U and generates a session key
SKRi= (gmi)ni.
• After extracting S from ξi, Uicomputes
C2i = C2i−1(P KR)(S+i)mod p = ξ(gRKR) i−1 j=1 (S+j) (gRKR)(S+i))mod p = ξ(gRKR) i j=1 (S+j) mod p.
• Ui generates M ACi= H(C1, C2i, X,
KPUˆ ={gn1, . . . , gni}, S).
• Ui delivers the message CRi,i+1={C1,
C2i, X, KPUˆ, M ACi} to the next user Ui+1. Step 5) After receiving CR| ˆU|,R, URchecks M AC| ˆU|by S.
If validated, then URcan authenticate all group users
Ui∈ U as follows. • URcomputes C1= g (| ˆU| j=1(S+j))mod p. • URderives ξby computing C2| ˆU|C1RKR−1mod p = ξ(gRKR) | ˆU| j=1 (S+j) × g | ˆU| j=1 (S+j) RKR −1 mod p = ξ.
• UR checks the validity of ξ={IDR}. If so,
Ui∈ ˆU are authenticated.
• UR then generates the session keys SKRi = (gni)mito protect the sessions with group users
Ui∈ U.
Different from the other two protocols, in the certificate-based protocol, UR knows whether Ui is authenticated by checking the value of| ˆj=1U| (S + j). In a group of three users, for example, UR obtains
3
j=1(S + j) = 3S + 6 if all group users are authenticated. Therefore, if a smaller value, for exam-ple, 2S + 4, is received, it is implied that some user (U2) has
failed the authentication.
V. CORRECTNESS ANDSECURITYANALYSIS
A. Correctness Analysis
In this section, we demonstrate the formula correctness of our protocols.
1) Hash-Based Protocol:
• User group authentication. As mentioned in Section IV-A, Step 3, each Ui computes Mi= Mi−1⊕H((NR+NA)⊕
hi). If 1≤i≤| ˆU|. Then, M| ˆU|= H((NR+NA)⊕h1)⊕ H((NR+NA)⊕h2)⊕· · ·⊕H((NR+NA)⊕h| ˆU|. There-fore, in Section IV-A, Step 4, UR will check whether
M| ˆU|= M? | ˆU|holds, which is verified as follows:
M| ˆU|= H ((NR+ NA)⊕ h1)⊕ H ((NR+ NA)⊕ h2) ⊕ . . . ⊕ H(NR+ NA)⊕ h| ˆU|
= M| ˆU|.
• Requester authentication. In Section IV-A, Step 4, UR computes Si= H((NR+ NA+ 1)⊕ hi) for each Ui. As
a result, in Step 5, each Uican authenticate URby check-ing whether Si= S? iholds as follows:
Si= H ((NR+ NA+ 1)⊕ hi) = Si.
2) Proxy-Based Protocol:
• User group authentication. In Section IV-B Step 3, each
Ui contributes its own key KAi into C2i. If 1≤ i ≤ | ˆU|, then C2ievolves into C2| ˆU|as follows:
C2i = C2A× C1(KAi) for 1≤ i ≤ | ˆU| = ξgr(KRA+NR)× gr(KA1)× gr(KA2)× · · · × gr(KA| ˆU|) = ξgr(KRA+NR)× gr(KA1)+r(KA2)+···+r(KA| ˆU|) = ξg r KRA+NR+ | ˆU| j=1 KAj = C2| ˆU|.
As a result, in Section IV-B, Step 4, URwill authenticate the group users by checking whether ξ ?= ξ holds, which follows the ElGamal proxy decryption and is verified as follows: ξ= C2| ˆU|× C1 (KRA+NR+ | ˆU| j=1 KAj) −1 = ξg r KRA+NR+ | ˆU| j=1 KAj × g r KRA+NR+ | ˆU| j=1 KAj −1 = ξ mod p.
• Requester authentication. In Section IV-B, Step 4, UR embeds its NAinto C2| ˆU|to form C2as follows:
C2= C2| ˆU|× C1NA = ξg r KRA+NR+ | ˆU| j=1 KAj × gr(NA) = ξg r KRA+NR+NA+ | ˆU| j=1 KAj .
Therefore, in Section IV-B, Step 5, each Uialso verifies the validity of UR by checking whether the form and
content of ξ are correct. The decryption formula of ξ is shown as follows: ξ= C2× C1 KRA+NR+NA+ | ˆU| j=1 KAj −1 = ξg r KRA+NR+ | ˆU| j=1 KAj × g r KRA+NR+NA+ | ˆU| j=1 KAj −1 = ξ mod p. 3) Certificate-Based Protocol:
• User group authentication. In Section IV-C Step 4, U1
first generates C21= ξ(P KR)S+1= ξ(gRKR)S+1, and then, each Uifor 2 < i≤ | ˆU| contributes their (S + i) into
C2i. In the end, C2| ˆU|is formed as follows:
C2| ˆU|= C21× (P KR)(S+2)× (P KR)(S+3) × · · · × (P KR)(S+| ˆU|) mod p = ξ(gRKR)(S+1)× (gRKR)(S+2) × · · · × (gRKR)(S+| ˆU|)mod p = ξ(gRKR) | ˆU| j=1 (S+j) mod p.
Finally, in Section IV-C, Step 5, UR computes C1=
g(
| ˆU|
j=1(S+j)) for decryption, which follows the
proce-dure for the ElGamal proxy cryptography. After obtaining
ξ, UR can confirm whether the content of ξ is legiti-mate. The correctness of the decryption is presented as follows: C2| ˆU|= C2| ˆU|(C1RKR)−1mod p = ξ(gRKR) | ˆU| j=1 (S+j) g | ˆU| j=1 (S+j) RKR −1 mod p = ξ.
• Requester authentication. Because the requester authenti-cation is achieved by the verifiauthenti-cation of UR’s signature, the correctness of signature verification is referenced by the Shamir–Tauman online/offline signature [16].
B. Security Analysis
This section gives security proofs and analyzes the proposed protocols. Due to space limitations, we briefly introduce the
security model and follow the concept of formal security proofs to reduce our protocols to well-known hard problems.3
Sim-ilar to [15], we prove the security of proxy- and certificate-based protocols certificate-based on the decision Diffie–Hellman (DDH) assumption [19], [20]. Then, we prove that the hash-based batch authentication protocol is secure against passive adversaries, impersonators, and implicit key authentication attacks by ap-plying the concept of the random-oracle model [18].
1) Security Model and Concepts: In 1993, Bellare and
Rog-away [18] proposed a theoretical security proof for an authenti-cation and key agreement protocol, called the BR93-Model. In our security analyses, we take the BR93-Model as a foundation for defining the security analysis concept.
Protocol Participants: iU
∗,R denotes the user oracle, which plays the role U∗ of interacting with R in the ith session, andjR,U
∗ denotes the server oracle, which plays the
role R of interacting with U∗ in the jth session. Note that, in our scheme, the server is regarded as the combination of the authenticator and the requester. Let F be the proposed authentication protocols. During the execution ofF, an adver-sary E who is a probabilistic polynomial-time Turing machine can control the entire network and obtain transmitted data in previous processes. The predefined oracle queries are listed as follows.
• Execute (iU∗,R,jR,U∗). The query models all kinds of passive attacks, where a passive adversary can eavesdrop on all transmitted data betweeniU∗,RandjR,U∗ in the protocolF.
• Send (iU∗,R, ξ). The query models an active attack,
where an adversary sends a message ξ to iU∗,R. The adversary can get the response message according to the sending message ξ in the protocol F. An adversary can initiate a session by setting ξ = λ.
• Send (jR,U
∗, ξ). The query also models active attacks,
where an adversary sends a message ξ to jR,U
∗. The
adversary can get the response message according to the sending message ξ in the protocolF.
• Reveal (iU∗,R). This query models the exposure of the old session key of instance i.
• Hash(). This query allows an adversary to ask the hash function value, and the challenger (or the simulator) an-swers all Hash() queries at random, just like real oracles would.
• Test (iU∗,R). IfiU∗,Raccepts and shares a session key with the partner oraclejR,U∗, the adversary E can launch the query to distinguish a real session key from a random string. The query models the adversary’s queries of the test oracle. Depending on a random coin bit, the adversary
E is given the real session key or a randomly chosen
string.
Security in the model is defined using the game G, which is played between the adversary E and a collection of oracles
3More specifically, we will not claim that our analysis is a formal security proof, because the details of query operations and probability calculation are omitted. See [29], [30] for a more formal proof.
i U∗,R/
j
R,U∗. The adversary E runs the game simulationG
with the following setting.
Step 1) The adversary E can perform Execute, Send, Reveal, Hash, and Test queries in the simulation. Step 2) At any moment during G, E can choose a fresh
session and send a Test query to the fresh oracle that is associated with the test session. Depending on a randomly chosen bit β ∈ {0, 1}, the challenger returns either a real session key or a randomly cho-sen string.
Step 3) E continues issuing the aforementioned Execute, Send, Reveal, and Hash queries.
Step 4) Finally, E terminates the game simulation and out-puts its guess bit β.
As we have done, we define the E’s guessing advantage as AdvE(k) =Pr[β = β]−1
2 where k is the security parameter.
Security Concept: The aforementioned queries represent
the abilities of an adversary in a real environment. The purpose of the adversary is to either pass the authentication procedure or distinguish the session key from a random string with a nonnegligible probability. Our security analysis follows the concept that if an adversary was able to be authenticated or to distinguish the session key, the adversary could solve some well-known computationally hard problems.
2) Security Proof by the DDH Assumption: In the
proxy- and certificate-based protocols, UR adopts the Shamir–Tauman online/offline signature protocol [16] to generate δ = Sign(RKR, C1). Therefore, we prove the security of proxy- and certificate-based batch authentication protocols by the DDH assumption [19], [20].
Assumption 1—DDH Problem: There are primes p and q
such that p = 2q + 1 and a generator g∈ Z∗p with order q for the subgroup Gq, where Gqis a subgroup of quadratic residues in Z∗p. For a given ya= gXa mod p and yb = gXbmod p, where Xa and Xb are randomly chosen from Z∗p, the fol-lowing two tuples of random variables (ya, yb, gXaXbmod p) and (ya, yb, W ), where W is a random value in Z∗p, are computationally indistinguishable. In other words, there is no efficient adversary algorithm E that satisfies|P r[E(gXa, gXb,
gXaXb) = true]− P r[E(gXa, gXb, R)] > (1/Q(|q|)) for any
polynomial Q, where the probability is higher than the random choice of Xa, Xb, and R.
In the proxy- and certificate-based batch authentication pro-tocols, messages are encrypted by the ElGamal proxy cryptog-raphy. Based on Assumption 1, [23] has proven that the security of the ElGamal encryption is as hard as the DDH problem. Here, we show how we can reduce our protocols to the ElGamal encryption.
Theorem 5.1: Under Assumption 1, the proposed protocol is
secure against passive adversaries.
Proof: In a proof by contradiction, assume that there
is an adversary E who can derive the message ξ that was encrypted by the ElGamal encryption (Z1 = αr= gr, Z2 =
ξβr= ξ((gx)r) mod p).
We construct another efficient algorithm E to obtain the message ξ that was encrypted by the ElGamal proxy encryp-tion. The adversary can perform the Execute query men-tioned in Section V-B-1 to obtain (C1, C2R), (C1, C2A), and (C1, C2i) for 1≤ i ≤ | ˆU| as the inputs of the algorithm
E. Without loss of generality, let C1 = Z1 = gtand C2 R=
ξ(gVR)t, where t, V
R, NR, and NA, V1, . . . , Vn−1are random numbers that were chosen from Z∗q. We compute the following values: C2A= C2R× C1NR = ξ(gVR)t× C1NR = ξgt(NR+VR) C21= C2A× C1V1 = ξg(NR+VR)t× C1V1 = ξgt(NR+VR+V1) .. . C2| ˆU|= C2| ˆU|−1× C1V| ˆU| = ξ g NR+VR+ | ˆU|−1 j=1 Vj t × C1V| ˆU| = ξg NR+VR+ | ˆU| j=1 Vj t = ξβr= Z2.
Now, the algorithm Ehas been constructed. Because E can derive the messages encrypted by the ElGamal encryption, by applying E, E can obtain the message ξ that was encrypted by the ElGamal proxy encryption, which is a contradiction to
Assumption 1.
Lemma 5.2: Under Assumption 1, any adversary E
can-not generate a valid C2i= ξg
r(KRA+NR+
| ˆU|
j=1KAj)mod p,
which can successfully be verified by the requester UR.
Proof: In our protocol, each user Ui generates C2i from
C2i−1. The message (C1, C2i, X) is broadcast, where C1 =
grmod p, C2
i= ξgr(NR+KRA+KA1+···+KAi)mod p, and the adversary E must compute C2ifrom these public parameters. Because the Advanced Encryption Standard (AES) algorithm is assumed to be secure [24], the parameter X is well protected. Obviously, the malicious adversary E must efficiently distin-guish (gr, ξgr(NR), ξgr(KRA+NR+KA1+···+KAi)mod p) from
(gr, ξgr(NR), W mod p), where W is a random value in Z∗
q. The problem is obviously a contradiction to Assumption 1. We then prove that no adversary E can pass the authentication
under Assumption 1.
Lemma 5.3: Assume that, by computing the discrete
logarithms modulo a large prime is difficult, any mali-cious adversary E cannot generate a signature protocol δ =
Sign(RKR, C1).
Proof: Because the signature δ = Sign(RKR, C1) is generated by the Shamir–Tauman online/offline signature pro-tocol, the security proof can directly refer to [16]. We briefly quote the conclusion. If the adversary E, without knowing
the secret key RKR, can impersonate UR to generate valid signatures with a nonnegligible probability , then the adversary
E can efficiently compute the discrete logarithms modulo a
large prime. Thus, the adversary E who tries to generate δ =
Sign(RKR, C1), indeed, needs the secret key RKR. In con-clusion, each user Ui can correctly authenticate the requester
URby signature δ = Sign(RKR, C1) under the assumption of
discrete logarithms.
Theorem 5.4: Under the discrete logarithm assumption and
Assumption 1, the proposed proxy- and certificate-based proto-cols are secure against impersonator attacks.
Proof: In this proof, we first show that the requester UR can authenticate each user Ui under the Diffie–Hellman prob-lem (DH) assumption. Then, each Uican also authenticate UR under the DDH problem assumption or the discrete logarithm problem (DLP) assumption [19].
By Lemma 5.2, we know that only legal requester UR and users Ui, who possess the secret shared key KAi with the authenticator UA, can generate C2 and C2i. Therefore, the protocols based on the ElGamal proxy encryption are secure against impersonator attacks.
By Lemma 5.3, it is clear that only legal requester UR, who holds RKR, can generate the signature δ = Sign(RKR, C1). Because the adversary has no access to the legal requester’s secret key RKR, he/she cannot generate a valid signature δ. Thus, we prove that the proposed proxy- and certificate-based protocols are secure against impersonator attacks and provide
mutual authentication.
Theorem 5.5: Under the discrete logarithm assumption and
Assumption 1, the proposed proxy- and certificate-based proto-cols can provide implicit key authentication.
Proof: By Lemma 5.2, we know that any malicious
ad-versary cannot generate C2Rand use it to derive the key agree-ment parameter gmi under the assumption of DLP. Although
the counterpart of key agreement parameter gni is transferred
in plaintext, M ACi can be used to withstand the malicious adversary under the security of AES [24] and the ElGamal proxy encryption. Because “NA+ NR+ KRA+
| ˆU| j=1KAj” and “S” are well protected by AES and the ElGamal proxy encryption, these values can be used to generate a valid M ACi. Hence, the proposed proxy- and certificate-based protocols, taking the ElGamal proxy encryption as their basis, are proved
to offer the implicit key authentication.
Theorem 5.6: Under the discrete logarithm assumption and
Assumption 1, the proposed protocols provide forward secrecy.
Proof: In this proof, we first prove that the proxy- and
certificate-based protocols guarantee forward secrecy and then show that the hash-based protocol also provides forward se-crecy as follows.
• The key agreement handshakes between UR and Ui are independent of the secret key KRA and KAi. Without loss of generality, let Up={U1, U2, . . . , Un} be the set of users who have established a session key SKRpwith URat some past time τ . After closing the session, the session key
SKRpwill be tossed. Suppose that an adversary E obtains a secret key KApof any user Upand the secret key SKRA of UR at time τ + 1. Because the session key SKRp is
isolated from the secret key KAp, the adversary E cannot obtain the session key SKRp. In the case that the adversary
E obtains gmp or gnp, he/she can compute the session
key SKRp. By Lemma 5.2, we know that the adversary
E cannot obtain mp or np from gmp or gnp under the assumption of discrete logarithms. We hence prove that our protocols guarantee forward secrecy.
• In the hash-based batch authentication protocol, we ex-ploit the DH key agreement to negotiate the session key. Therefore, its security of forward secrecy is the same as
previously mentioned.
3) Security Proof by Random Oracle Concept: According
to the concept of the random-oracle model [18], which assumes that the one-way hash function is a fair random function, we can prove that the proposed hash-based batch authentication protocol is secure against passive adversaries, impersonators, and implicit key authentication attacks.
Theorem 5.7: Under the assumption of the discrete
loga-rithm and the robust one-way hash function, the proposed hash-based protocol is secure against passive adversaries.
Proof: If the adversary cannot acquire any critical
mean-ing information from the messages transmitted in the public channel, the proposed hash-based protocol is secure against passive adversaries. In the hash-based batch authentication pro-tocol, most messages are operated by exclusive ORs (XORs) and the one-way hash function as follows.
• Because the XOR operation is widely adapted to several famous systems [21], [22] to mix with messages that infer that the XOR operation is suited to hide information, we also apply XORs to conceal the information.
• The most important information hi is protected by the one-way hash function. Under the concept of the random-oracle model [18], the probability is negligible when the adversary tries to extract hi from Mi+2= H((NR+
NA)⊕ hi). For M ACi, the security of the message au-thentication code is also under the concept of the random-oracle model due to the indistinguishability of the one-way hash function.
Although the parameters of key agreement gni are exposed
to the public, the assumption of a discrete logarithm ensures that the adversary does not have the nonnegligible advantage to know the value of ni. As a result, the hash-based batch authentication protocol is secure against a passive attack.
Theorem 5.8: As long as the one-way hash function is
ro-bust, the proposed hash-based batch authentication protocol is secure against impersonator attacks.
Proof: An impersonator attack is an attack where the
adversary acts on behalf of other users to pass the authen-tication. To impersonate a legal user, the adversary needs to obtain hi, NR, and NA. Under the concept of the random-oracle model, which assumes that the one-way hash function is robust, the probability that the adversary obtains hi, NR, and NA from Mi+2 is negligible. The adversary may extract (hi−2, h(KAi),
2
j=1Nj, gmi) if he/she knows the preshared keys KAiand tibetween Uiand UA. Because shared key KAiis well protected by the one-way hash function, under the concept
TABLE II
PERFORMANCECOMPARISONS OF THEUNDERLYINGCRYPTOGRAPHIES
of the random-oracle model, the probability of compromising the shared key from the transmitted messages is negligible. Thus, our hash-based protocol is secure against impersonator
attacks.
Theorem 5.9: Under the assumption of a discrete logarithm
and the robust one-way hash function, the proposed hash-based protocol is secure against implicit key authentication.
Proof: In the hash-based protocol, two parameters of key
agreement are exchanged during handshake as follows. • gni is transmitted in plaintext, but its integrity can be
guaranteed by M ACi. • gmiis protected by H(r, (K
Aiti)). Under the concept of the random-oracle model, only the legal Uiwho possesses the shared key KAi can obtain the gmi. Based on the discrete logarithm assumption, no one can obtain the value of ni, except for the legal Ui.
Therefore, the implicit key authentication is provided in our
hash-based protocol.
VI. COMPARISONS
In this section, we compare our protocols with the Kerberos, ElGamal, and other existing authentication protocols. Because our architecture is similar to Kerberos [25], [26], we first compare our protocols with Kerberos when authenticating multiple users. Table II compares the proposed protocols with Kerberos in terms of the communication cost, computational cost, the underlying cryptosystems, trustworthiness relation-ship, and the support of trust level. While authenticating n users, the Kerberos protocol requires 6n messages to com-pletely authenticate all users. In contrast, the proposed proto-cols require at most 2n + 2 messages. To show the advantage of our batch concept, a comparison with the traditional ElGamal encryption is also presented. While authenticating n users, the total number of messages is 2× ((n · (n − 1))/2) = n2− n.
The reason is that the traditional ElGamal encryption requires two messages to achieve mutual authentication. Moreover, if
n users try to authenticate the other users, the number of
authentication times is ((n· (n − 1))/2). Fig. 7 illustrates the comparison of communication cost among our framework, Kerberos, and ElGamal encryption. As shown, our scheme outperforms the other schemes. Moreover, the performance ad-vantage increases with an increase in the number of users to be authenticated.
Because the hash-based protocol takes a one-way hash func-tion as its underlying cryptosystem, its computafunc-tional costs are extremely low. Because the proposed certificate-based batch
Fig. 7. Communication cost versus the number of users to be authenticated.
authentication protocol adopts the ElGamal proxy encryption scheme and public key infrastructure, its computational cost is the highest, but it requires the fewest messages for authenti-cation. With regard to trustworthiness, both Kerberos and the proposed hash-based protocol build trustworthiness between the requester UR and individual user Ui. By applying the proxy- and certificate-based protocols, we can build complete trustworthiness among all entities, including UA, UR, and Ui∈
U . In our protocols, the trust level can be used to distinguish
the level of trustworthiness. For example, a face-to-face au-thentication leads to a higher trust level, whereas P2P-based authentication has a lower trust level. In our protocols, only the proxy- and certificate-based protocols provide trust level during authentication. By the provided trust level, entities can predefine a trust level threshold to determine whether to accept the user as a trusted friend.
In Table III, we compare our protocols with other P2P-based authentication protocols with respect to the require-ments mentioned in Section III. Most protocols provide mutual authentication among entities, but none of the existing pro-tocols offers batch authentication. The proposed proxy- and certificate-based protocols also support user reputation by the trust level. Moreover, the certificate-based protocol also offers nonrepudiation by signing the messages. Because no central-ized server is involved in our design, the proposed protocols can be adapted to any OSN, either web- or P2P-based architecture. Our framework also supports comprehensive hardware, from resource-limited to powerful computing devices. As previously mentioned, the hash-based protocol takes only a one-way hash function as its underlying cryptosystem and, hence, is cost effective. In short, our protocols meet most of the requirements mentioned in Section III.
