Identity-Based Authentication for Cloud Computing

Hongwei Li1, Yuanshun Dai1,2, Ling Tian1, and Haomiao Yang1

1

Collaborative Autonomic Computing Lab, School of Computer Science and Engineering,

University of Electronic Science and Technology of China
[email protected], [email protected], [email protected]
2
Innovative Computing Lab, Department of Electronic Engineering & Computer Science,
University of Tennessee, Knoxville, USA
[email protected]

Abstract. Cloud computing is a recently developed new technology for

complex systems with massive-scale services sharing among numerous users.
Therefore, authentication of both users and services is a significant issue for the
trust and security of the cloud computing. SSL Authentication Protocol (SAP),
once applied in cloud computing, will become so complicated that users will
undergo a heavily loaded point both in computation and communication. This
paper, based on the identity-based hierarchical model for cloud computing
(IBHMCC) and its corresponding encryption and signature schemes, presented
a new identity-based authentication protocol for cloud computing and services.
Through simulation testing, it is shown that the authentication protocol is more
lightweight and efficient than SAP, specially the more lightweight user side.
Such merit of our model with great scalability is very suited to the massivescale cloud.
Keywords: cloud computing, identity-based cryptography, authentication.

1 Introduction
Cloud computing is a style of computing in which dynamically scalable and often
virtualized resources are provided as a service over the Internet. Users need not have
knowledge of, expertise in, or control over the technology infrastructure in the cloud
that supports them [1,2]. Authentication, thus, becomes pretty important for cloud
security. Applied to cloud computing and based on standard X.509 certificate-based
PKI authentication framework, SSL Authentication Protocol (SAP) [3] is low
efficient. The authors of Grid Security Infrastructure (GSI) conceded that the current
GSI technique has a poor scalability [4]. W.B. Mao analyzed that this scalability
problem is an inherent one due to the use of SAP [5].
Grid computing and cloud computing are so similar that grid security technique
can be applied to cloud computing. Dai et al. made great contribution to Grid security
[6-9]. Recently, identity-based cryptography (IBC) is developing very quickly [1012]. The idea of applying IBC to grid security was initially explored by Lim (2004)
[13]. Mao et al. (2004) proposed an identity-based non-interactive authentication
framework for grid [5]. The framework is certificate-free. But the unique Private Key
M.G. Jaatun, G. Zhao, and C. Rong (Eds.): CloudCom 2009, LNCS 5931, pp. 157166, 2009.
Springer-Verlag Berlin Heidelberg 2009

158

H. Li et al.

Generator (PKG) becomes the bottleneck of framework. Lim and Robshow (2005)
proposed a hybrid approach combining IBC [14]. The approach solves escrow and
distribution of private key. However, the non-interactive and certificate-free quality is
lost. Chen (2005) revisited the GSI in the GT version2 and improved the GSI
architecture and protocols [15]. It is significant to study IBC and cloud computing.
In this paper, based on identity-based hierarchical model for cloud computing
(IBHMCC) and corresponding encryption and signature schemes, an identity-based
authentication for cloud computing (IBACC) is proposed. IBACC is more efficient
and lightweight than SAP, specially the more lightweight user side, which contributes
good scalability to the much larger cloud systems.
The remaining of the paper is organized as the following. Section 2 introduces the
identity-based hierarchical model for cloud computing (IBHMCC). In section 3, we
propose identity-based encryption and signature technology for the IBHMCC.
Section 4 proposes identity-based authentication mechanism for cloud computing.
Section 5 makes the performance analysis for our new protocols and did simulated
experiments to validate the techniques.

2 Identity-Based Hierarchical Model for Cloud Computing

As shown in Fig.1, IBHM for cloud computing (IBHMCC) is composed of three
levels. The top level (level-0) is root PKG. The level-1 is sub-PKGs. Each node in
level-1 corresponds to a data-center (such as a Cloud Storage Service Provider) in the
cloud computing. The bottom level (level-2) are users in the cloud computing. In
IBHMCC, each node has a unique name. The name is the nodes registered
distinguished name ( DN ) when the node joins the cloud storage service. For
example, in the Fig.1, DN of the root node is DN 0 , DN of node M is DN M and

DN of node N is DN N . We define the identity of node is the DN string from the

root node to the current node itself. For example, the identity of entity N is
IDN = DN 0 || DN M || DN N . || denotes string concatenation. We further define
IDN |0 = DN 0 , IDN |1 = DN 0 || DN M , IDN |2 = DN 0 || DN M || DN N .The rule is applicable
to all nodes in the hierarchical model.
The deployment of IBHMCC needs two modules: Root PKG setup and Lowerlevel setup.

root

M
N
Fig. 1. IBHM for cloud computing

Identity-Based Authentication for Cloud Computing

159

Root PKG setup: Root PKG acts as follows:

1. Generate group G1 , G2 of some prime order q and an admissible pairing

: G1 G1 G2 ;
2. Choose an arbitrary generator P G1 ;
3. Choose cryptography hash functions H1 :{0,1}* G1 , H 2 : G2 {0,1}n for some
n;
4. Pick a random Z*q and set Q0 = P, P0 = H1 ( DN 0 ), S 0 = P0 . The root PKGs
master key is S0 and the system parameters are < G1 , G2 , , Q0 , P, P0 , H1 , H 2 > .
Lower-level setup

1.
2.

Assume there are m nodes in the level-1. For each node, the root PKG acts as
follows (let X be an arbitrary node in the m nodes ):
Compute the public key of node X : PX = H1 ( IDX ), where IDX = DN 0 || DN X ;

3.

Pick the secret point X Z*q for node X . X is only known by node X and its

4.

parent node;
Set the secret key of node X : S X = S0 + X PX ;

5.

Define the Q-value: QIDX |1 = X P . QIDX |1 is public.

After the above five steps are finished, all nodes in the level-1 get and securely keep
their secret keys and the secret points. On the other hand, the public key and the
Q-value are publicized.
Then, Each node in the level-1 similarly repeats the above steps (2-5). Similarly,
all nodes in level-2 keep the secret keys and the secret point while publicizing the
public key and Q-value.

3 Identity-Based Encryption and Signature for IBHMCC

In the cloud computing, it is frequent for the entities to communicate mutually. To
achieve the security in the communication, it is important to propose an encryption
and signature schemes. Therefore, we propose an identity-based encryption (IBE) and
identity-based signature (IBS) schemes for IBHMCC in the following.
3.1 Identity-Based Encryption

IBE is based on the above Root PKG setup and Lower-level setup algorithms. It is
composed by two parts: Encryption and Decryption.
Encryption: Assume E1 and E2 are two entities in the cloud computing. The identity

of entity E2 is IDE2 = DN 0 || DN1 || DN 2 . To encrypt message m with IDE2 , E1 acts

as follows:
1.

Compute
P1 = H1 ( DN 0 || DN1 )

(1)

160

H. Li et al.

P2 = H1 ( DN 0 || DN1 || DN 2 )

(2)

2. Choose a random r Z*q ;

3. Output the ciphertext
C =< rP, rP1 , rP2 , H 2 ( g r ) m >

(3)

where g = (Q0 , P0 ) which can be pre-computed.

Decryption: After receiving the ciphertext C =< U 0 ,U1 , U 2 ,V >, entity E2 can

decrypt C using its secret key S E2 = S0 + 1 P1 + 2 P2 , where 1 is the secret point of

node DN 0 || DN1 , 2 is the secret point of node DN 0 || DN1 || DN 2 :
1. Compute
d=

(U 0 , S E2 )
2

(Q

i =1

IDE2 |i

(4)

,U i )

where QIDE2 |1 = 1 P, QIDE2 |2 = 2 P ;

2. Output the message m = H 2 (d ) V .
3.2 Identity-Based Signature

IBS is also based on Root PKG setup and Lower-level setup algorithms. It
incorporates two algorithms: signature and verification.
Signature: To sign message m , entity E2 acts as follows:

1. Compute Pm = H1 ( DN 0 || DN1 || DN 2 || m) ;
2. Compute = S E2 + 2 Pm , where 2 is the secret point of entity E2 ;
3. Output the signature < , Pm , QIDE2 |1 , QIDE2 |2 > .
Verification: Other Entities can verify the signature by acting as follows: Confirm

( P, ) = ( P, 2 Pm ) (Q0 , P0 )

(Q
i =1

IDE2 |i

, Pi )

(5)

if the equation is true, the signature is validated.

4 Identity-Based Authentication for Cloud Computing

In this section, based on the former IBE and IBS schemes, an identity-based
authentication for cloud computing (IBACC) is proposed.

Identity-Based Authentication for Cloud Computing

161

(1) C S : ClientHello ( nC , ID, specificationC )

ClientHelloDone
(2) S C : ServerHello ( nS , ID, specificationS )
ServerKeyExchange ( EPC [ FCS ] )
IdentityVerify ( Sig SS [ M ] )
ServerHelloDone
(3) C S : ClientFinished
Fig. 2. Identity-based Authentication Protocol

where
nC , nS : the fresh random number
ID : the session identifier
specificationC : the cipher specification of C
specificationS : the cipher specification of S
FCS : a pre-master secret used to generate the shared key
EPC [ FCS ] : encrypt FCS with the public key PC of entity C using the encryption
algorithm of IBE
M : all handshake messages since the ClientHello message
Sig SS [ M ] : sign M with the private key SS of entity S using the signature
algorithm of IBS
In step (1), the client C sends the server S a ClientHello message. The message
contains a fresh random number nC , session identifier ID and specificationC .
SpecificationC extends from TLS to handle the IBE and IBS schemes. For example,
SpecificationC could be the form TLS _ IBE _ IBS _ WITH _ SHA _ AES . IBE and
IBS are used as secure transporting and authentication. SHA is the hash function.
AES is the symmetric encryption algorithm.
In step (2), the server S responds with a ServerHello message which contains a
new fresh random number nS , the session identifier ID and the cipher
specification specificationS . The specificationS is S s supporting ciphersuite.
Then C chooses a pre-master secret FCS and encrypts it with the public key PC of
entity C using the encryption algorithm of IBE. The ciphertext is transmitted to C as
ServerKeyExchange message. Then S generates a signature Sig SS [ M ] as the
IdentityVerify message to forward to C . Finally, The ServerHelloDone message
means the step (2) is over.
In step (3), C firstly verifies the signature Sig SS [ M ] with the help of IDS . Pass of
verification means S is the valid owner of IDS . This completes authentication form

162

H. Li et al.

S to C .Then C decrypts the EPC [ FCS ] with its private key SC . Because of the fresh
FCS , the correct decryption indicates C is the valid owner of IDC . This step
authenticates the validity of C . The ServerFinished message means the step (3) finishes.
Eventually, a shared secret key between C and S is calculated by KCS =
PRF ( FCS , nC , nS ) , where PRF is pseudo-random function.

5 Performance Analysis and Simulation

In this section, performance comparisons between SAP and IBACC are firstly
discussed. Then simulation experiment gives precise results.
5.1 Communication Cost

The comparison of communication cost between the two different protocols is shown
in table 1. Note that only dominant communication is considered, i.e. certificate,
signed or encrypted messages, which may have the greatest consumptions of the
network bandwidth.
Table 1. Comparison of communication cost

Certificate

SAP
RSA Signature

IBS Signature

IBACC
IBE Ciphertext

Reference [3] shows that communication cost of SAP is two public key certificates
and two RSA signatures. However, in the IBACC, the communication cost is only one
IBS signature and one IBE ciphertext.
5.2 Computation Cost

The comparison of computation cost between the two different protocols is shown in
table 2. Note that only dominant computation is considered, i.e. encryption,
decryption and authentication.
Table 2. Comparison of computation cost
SAP

IBACC

Client

1 ENCR , 1 SIGR and Authenticating server

1 ENCI and 1 SIGI

Server

1 DECR , 1 SIGR and Authenticating client

1 DECI and 1 VERI

Where
ENCR = RSA encryption
DECR = RSA decryption

Identity-Based Authentication for Cloud Computing

163

ENCI = IBE encryption

DECI = IBE decryption
SIGR = RSA signature
SIGI = IBS signature
VERI = IBS signature verification
Authenticating server=Including building certification path of server and verifying
signatures.
Authenticating client= Including building certification path of client and verifying
signatures.
The paper [3] showed that in the SAP, the computation cost of client was one RSA
encryption, one RSA signature and Authenticating server. The computation cost of
server was one RSA decryption, one RSA signature and Authenticating client.
However, in the IBACC, the computation cost of client is one IBE encryption and one
IBS signature. The computation cost of server is one IBE decryption and one IBS
signature verification.
5.3 Simulation and Experiment Results
Simulation Platform and Reference
The platform of simulation experiment is GridSim [16] which is a simulation
platform based on Java. Special users and resources can be generated by rewriting
these interfaces. This aligns well with various users and resources of cloud
computing. Furthermore, GridSim is based on SimJava which is a discrete event
simulation tool based on Java and simulates various entities by multiple thread. This
aligns well with randomness of cloud computing entity action. Therefore, it is
feasible to simulate our proposed authentication protocol of cloud computing by
GridSim.
The simulation environment is composed of four computers which are all
equipped with P4 3.0 CPU, 2G memory. Certification chain is important for SAP.
The shorter, the better. The shortest certification chain includes all 4 certifications:
CA1 , client and CA2 , server. There are a cross authentication for CA1 and CA2 . It is
in this scene that SAP and IBACC are compared. Based on openssl0.9.7, SAP is
implemented. Pairing computing adapts the algorithms of reference [17]. To
precisely simulate the network delay, there are 25~45ms waiting time before
messages are sent.
Simulation Results and Analysis
Fig.3 illustrates the authentication time of IBACC is approximately 571 ms while that
of SAP is 980 ms. That is to say, authentication time of IBACC is 58% of that of
SAP. Fig.4 shows thecommunication cost of IBACC is approximately 1785 bytes
while that of SAP is 5852 bytes. That is to say, communication cost of IBACC is 31%
of that of SAP. The simulation results confirm that the communication cost of IBACC
is less and the authentication time is shorter.

164

H. Li et al.

IBACC

e
m
i
t
n
o
i
t
a
c
i
t
n
e
h
t
u
a

SAP

1500
1000

)
s
m
(

500
0

1
IBACC 560
980
SAP

2
573
973

3
4
5
6
567 571 562 578
988 993 968 983
simulation time

7
566
984

8
576
975

Fig. 3. Comparison of authentication time

IBACC
t
s
o
c
n
o
i
t
a
c
i
n
u
m
m
o
c

SAP

8000
6000

)
s
e
t
y
b
(

4000
2000
0

1
2
3
4
5
6
7
8
IBACC 1782 1883 1785 1788 1889 1792 1779 1784
5858 5844 5847 5833 5855 5845 5882 5849
SAP
simulation time

Fig. 4. Comparison of communication cost

IBACC

e
m
i
t
n
o
i
t
a
t
u
p
m
o
c

)
s
m
(
t
n
e
i
l
c
f
o

SAP

300
200
100
0

IBACC 41
276
SAP

2
42
258

41
40
39
38
266 275 277 276
simulation time

43
273

44
270

Fig. 5. Comparison of computation time of client

Identity-Based Authentication for Cloud Computing

IBACC

e
m
i
t
n
o
i
t
a
t
u
p
m
o
c

)
s
m
(
r
e
v
r
e
s
f
o

165

SAP

400
300
200
100
0

1
IBACC 202
315
SAP

2
201
314

3
4
5
6
199 198 205 204
311 310 316 318
simulation time

7
203
312

8
201
313

Fig. 6. Comparison of computation time of server

As shown in Fig.5, computation time of client for IBACC is approximately 41 ms

while that for SAP is 272 ms. That is to say, computation time of client for IBACC is
15% of that for SAP. Fig.6 illustrates computation time of server for IBACC is
approximately 202 ms while that for SAP is 313 ms. That is to say, computation time
of server for IBACC is 65% of that for SAP. The simulation results confirm that both
client and server of IBACC are more lightweight than those of SAP.
Furthermore, computation time of client is 20% of that of server in IBACC. This
aligns well with the idea of cloud computing which allows the user with an average or
low-end platform to outsource its computational tasks to more powerful servers. As a
result, the more lightweight user side can connect more servers and contribute to the
larger scalability.

6 Conclusion
Authentication is necessary in Cloud Computing. SSL Authentication Protocol is of
low efficiency for Cloud services and users. In this paper, we presented an identitybased authentication for cloud computing, based on the identity-based hierarchical
model for cloud computing (IBHMCC) and corresponding encryption and signature
schemes. Being certificate-free, the authentication protocol aligned well with
demands of cloud computing. Performance analysis indicated that the authentication
protocol is more efficient and lightweight than SAP, especially the more lightweight
user side. This aligned well with the idea of cloud computing to allow the users with
an average or low-end platform to outsource their computational tasks to more
powerful servers.

References
1. Erdogmus, H.: Cloud Computing: Does Nirvana Hide behind the Nebula? IEEE
Software 26(2), 46 (2009)
2. Leavitt, N.: Is Cloud Computing Really Ready for Prime Time? Computer 42(1), 1520
(2009)

166

H. Li et al.

3. Freier, A.O., Karlton, P., Kocher, P.C.: The SSL Protocol, Version 3.0.INTERNETDRAFT (November 1996), http://draft-freier-ssl-version3-02.txt
4. Foster, I., Kesslman, C., Tsudik, G.: A Security Architecture for Computational Grids. In:
ACM Conference on Computers and Security, pp. 8390 (1998)
5. Mao, W.B.: An Identity-based Non- interactive Authentication Framework for
Computational Grids, May 29 (2004),
http://www.hpl.hp.com/techreports/2004/HPL-2004-96.pdf
6. Dai, Y.S., Pan, Y., Zou, X.K.: A hierarchical modelling and analysis for grid service
reliability. IEEE Transactions on Computers 56(5), 681691 (2007)
7. Dai, Y.S., Levitin, G., Trivedi, K.S.: Performance and Reliability of Tree-Structured Grid
Services Considering Data Dependence and Failure Correlation. IEEE Transactions on
Computers 56(7), 925936 (2007)
8. Dai, Y.S., Levitin, G.: Reliability and Performance of Tree-structured Grid Services. IEEE
Transactions on Reliability 55(2), 337349 (2006)
9. Dai, Y.S., Xie, M., Wang, X.L.: Heuristic Algorithm for Reliability Modeling and
Analysis of Grid Systems. IEEE Transactions on Systems, Man, and Cybernetics, Part
A 37(2), 189200 (2007)
10. Boneh, D., Gentry, C., Hamburg, M.: Space Efficient Identity Based Encryption without
Pairings. In: Proceedings of FOCS 2007, pp. 647657 (2007)
11. Boneh, D.: Generalized Identity Based and Broadcast Encryption Schemes. In: Pieprzyk, J.
(ed.) ASIACRYPT 2008. LNCS, vol. 5350, pp. 455470. Springer, Heidelberg (2008)
12. Boyen, X.: General Ad Hoc Encryption from Exponent Inversion IBE. In: Naor, M. (ed.)
EUROCRYPT 2007. LNCS, vol. 4515, pp. 394411. Springer, Heidelberg (2007)
13. Lim, H.W., Robshaw, M.: On Identity- Based. Cryptography and Grid Computing. In:
Bubak, M., van Albada, G.D., Sloot, P.M.A., Dongarra, J. (eds.) ICCS 2004. LNCS,
vol. 3036, pp. 474477. Springer, Heidelberg (2004)
14. Lim, H.W., Robshaw, M.: A dynamic key infrastructure for GRID. In: Sloot, P.M.A.,
Hoekstra, A.G., Priol, T., Reinefeld, A., Bubak, M. (eds.) EGC 2005. LNCS, vol. 3470,
pp. 255264. Springer, Heidelberg (2005)
15. Chen, L., Lim, H.W., Mao, W.B.: User-friendly grid security architecture and protocols.
In: Proceedings of the 13th International Workshop on Security Protocols (2005)
16. Buyya, R., Murshed, M.: GridSim: a toolkit for the modeling and simulation of distributed
resource management and scheduling for grid computing. Journal of concurrency and
computation practice and experience 14(13-15), 11751220 (2002)
17. Barreto, P.S.L.M., Kim, H.Y., Lynn, B., Scott, M.: Efficient algorithms for pairing-based
cryptosystems. In: Yung, M. (ed.) CRYPTO 2002. LNCS, vol. 2442, pp. 354368.
Springer, Heidelberg (2002)