A blind signature-based approach for cross-

domain authentication in the cloud environment

Aniello Castiglione

1Francesco Palmieri

2, Chin-Ling Chen

3, and Yao-Chung Chang

3

1

Università degli Studi di Salerno

Dipartimento di Informatica “R.M. Capocelli”

Via Ponte don Melillo, I-84084 Fisciano (SA), ITALY

2Seconda Università degli Studi di Napoli

Dipartimento di Ingegneria Industriale e dell’Informazione

Via Roma 29, I-81031, Aversa (CE), ITALY

3

Chaoyang University of Technology

Department of Computer Science and Information Engineering,

168, Jifeng E. Rd., Wufeng District, Taichung, 41349 Taiwan, R.O.C

ABSTRACT In recent years, Cloud services have become an important part of people’s lives, providing them with a

large amount of IT resources, available from anywhere and at any time. The access to the services offered

is controlled basing on users’ identification credentials. As people acquire services from multiple cloud

providers, in order to avoid the proliferation of identities associated to a single user, new cross-

organization authentication methods, allowing the authorized transfer of users’ identification data from

one Cloud to another, are emerging. However, since most of these techniques do not protect adequately

users’ private information, attackers can easily intercept and tamper with confidential identity-related

messages. In this paper, we use the characteristics of blind signatures to support user verification of the

registering provider, to protect the user’s identity, and to address known vulnerabilities in these systems.

In addition, we use a strong designated verifier signature with message recovery characteristics to

strengthen data communication security in the whole process.

INTRODUCTION

Cloud-based services are experiencing a rapid development in the last years due to their lower costs and

to their improved flexibility and scalability in dynamically growing together with the workload demands.

However, as the use of these technologies become widespread, new security requirements and challenges

associated with them emerge at a rapid pace.

From the cloud provider point of view, user identification is one of the most critical issues in order to

allow the subscribers to access the available services based on their own secure credentials. Furthermore,

the account information kept by provider organizations are associated with contains the user’s personal

data (gender, address, credit card numbers, etc.) that may become the target of fraud attacks, identity theft,

etc. Therefore, each involved cloud provider must guarantee the safety and privacy of such personal

2

information (Svantesson, D., & Clarke, R., 2010), and this may be a problem when the number of users

uncontrollably grows.

Most of the currently available cloud service infrastructures support centralized user identification

mechanisms based on proprietary solutions including, traditional username/password tuples, one time

passwords, tokens and digital signatures, all providing limited flexibility in their authentication systems.

This implied the proliferation of different digital identities that have to be used by the same user in order

to access the resources made available from different cloud providers.

However, with the recent development of fully distributed cloud architectures, based on the cooperation

of multiple federated sites and organizations, a strong paradigm shift from organization-centric to user-

centric identity management solution becomes indispensable in order to provide an adequate degree of

security also in more complex infrastructures, requiring the interaction between multiple users and service

provider entities within the same cloud. Each identity management solution require two logical

component entities: unique identifiers together with an authentication procedure based on their use.

Clearly, user-centricity in these components implies a greater scalability with an improved flexibility and

usability, easily supporting Single-Sign-On (SSO) mechanisms to be used in federated environments, in

order to cope with the multiple identities syndrome without registering the same personal identity on any

provider they rely on. Furthermore, the users of modern inter-cloud services should be free to choose their

own identity provider according to specific security and privacy requirements/policies as well as to their

personal trust relationship with the involved organization.

In this scenario, the OpenID standard (Recordon, D., & Reed, D., 2006) for user-centric digital identity,

has gained crescent popularity because of its open and decentralized nature, becoming the solution of

choice for the implementation of inter-cloud federated authentication. It is able to achieve cross-

application and cross-domain SSO (Armando A. et al., 2013) (Kurdi H. et al., 2014) (Tormo G. D., 2014)

allowing service providers to delegate the authentication of their users to other identity providers, greatly

reducing the maintenance costs associated to the management of user credentials. At the state-of-the-art

Google, like Yahoo! provides a federated login solution implemented by using OpenID 2.0, but is

migrating to OpenID Connect 1.0 and OAuth 2.0, also supported by MS Azure in its Active Directory

implementation as well as from RackSpace and Amazon Cognito. An OpenID-as-a-service solution for

OpenStack has been proposed in (R. Khan, J. Ylitalo, and A. Ahmed, 2011). however, it uses only a

single cloud organization to scale the OpenID service, which is susceptible to several threats and

performance issues.

Despite its wide acceptance in the cloud arena OpenID is essentially a lightweight solution to be used

only in the most “trivial” identity management tasks, typically not involving strategic activities. This is

because OpenID is not recognized as a trust system, suffers from several usability problems, is known to

be highly vulnerable to phishing and other attacks, introduces critical privacy problems, and hence makes

it unappealing to become an OpenID end-user or provider (Brands, S., 2007).

Starting for these considerations, in this work we proposed a new decentralized model for inter-cloud

identity management that addresses the known vulnerabilities in the OpenID system by using the

characteristics of blind signatures to support verification of the registering provider, protect the user’s

identity, and ensure enough degree of trust between all the involved entities and resistance to the most

common attacks. Being simple and effective in its implementation and interaction mechanisms among the

involved parties, it also improves the usability and seamless Single-Sign-On experience for the users. In

addition, the proposed framework relies on a strong designated verifier signature with message recovery

characteristics to strengthen data security and reduce the amount of communication between Clouds.

3

BACKGROUND

This section briefly introduces some of the basic concepts that will be useful in explaining the proposed

digital identity management framework, by presenting the current technological scenario as well as the

fundamental architectural elements behind it.

Security Problems in OpenID

OpenID is a passive protocol, allowing users to access multiple services by using the same digital identity.

It is based on the concept of relayed authentication implemented by using simple mechanisms such as

web redirections to communicate between the relying party and the remote identity provider (IdP).

Furthermore, OpenID does not need to build a token containing security attributes, but rather uses HTTP

query strings or POST Form elements to convey separate fields, greatly reducing the complexity without

the need of a specific parsing activity.

In particular, the OpenID protocol allows a user to declare its identity when communicating with a relying

party that can be, for example, an application or a Web site that needs to check its identity on an external

identity provider. Such communication is achieved by exchanging an identifier (the OpenID) that is the

XRI or URL adopted by the user to declare its identity. Such exchange is performed by a “User-Agent”

(that usually is a browser) adopted by the user in the communication between the relying party and the

OpenID provider.

The identity provider is located by using the Yadis discovery protocol (Miller, J., 2006) and all the

communication between the relying party and the identity provider is secured by using a shared key

negotiated through the Diffie-Hellman key exchange protocol (Diffie, W., & Hellman, M.,1976). The

whole schema is simply sketched in the following Fig. 1.

4

Fig. 1. The OpenID authentication scheme

Despite its simplicity and use of proved technologies and mechanisms, OpenID starting from its first

appearance has been considered insecure from the worldwide community. In fact, in 2005 OpenID

Foundation published a circular report (OpenID Foundation, 2005) warning all the OpenID users about

vulnerabilities in the Attribute Exchange process allows an attacker to alter or disclose the users' personal

information to be potentially used in subsequent hostile activities. Several other studies identified open

security weaknesses in OpenID, involving lack of privacy and failure in addressing the trust problem (Sun,

S. T., Hawkey, K., & Beznosov, K., 2012) (van Delft, B., & Oostdijk, M., 2010)(Brands, S., 2007).

They asserted that OpenID is proven to be vulnerable to phishing attacks. As an example, an hostile party

may decide to route the user to a fake authentication page requesting the user to provide its credentials.

After that, the hostile party (who controls also the fake authentication page) will have access to the user’s

credentials within the identity provider and it will be able to employ the user’s OpenID with different

services. Furthermore, (Barth et al., 2008) proved how the OpenID is exposed to the attack named

“session swapping” that is an attack in which the user’s browser is forced to initialized a Web session by

authenticating him as the attacker.

An additional crucial vulnerability arises associated to the URL redirection from the IdP to the relying

entity, in the concluding step of the authentication scheme when the TLS/SSL protocol is not adopted for

ensuring end-to-end security. The issue with that redirection is the replay attack: in fact whoever will be

able to know that URL (by means of several network attacks, such as sniffing and so on) will be able to

replay it and impersonate the attacked user on the authenticating Web site. Luckily, the adoption of the

TLS/SSL protocol during the authentication phase, gets rid of this risk. In a similar way, (Sovis, P.,

Kohlar, F., & Schwenk, I., 2010) analyzed the OpenID extension protocol and realized that some

5

extension parameters, if not using a TLS/SSL channel, could be faked. This attack is usually known as

“parameter forgery” attack.

To sum up, the absence of authentication and encryption in several parts of the protocols leads to the

above-mentioned security issues. Clearly, the main consequence is that an attacker can easily tamper the

communication between the involved parties or introduce some malicious relay or identity provider entity

in order to acquire or modify the user secret credentials or attributes. Therefore, we propose a more secure

inter-cloud authentication process relying on blind signatures and designated verifier schemes to cope

with all the above security issues.

Blind Signatures

A blind signature is a particular type of digital signature that hides the content of the involved message

before signing it. However, such kind of signature allows verification on the original, clear text message

as in normal digital signature mechanisms. The original blind signature scheme, based on traditional RSA

digital signatures, has been introduced in (Chaum, D., 1982), as an effective method for signing and

hence authenticating digital messages without the need of knowing their contents as well as the signatures

that will be used by the recipients, and without exposing the identity of the original message’s author for

which authentication is performed. The signing entities need to protect their own private keys and to

perform distribution, through proper authentication channels, of their associated public keys, to be used

for later verification, like in traditional digital signature paradigms.

Blind signature schemes have been implemented by using many digital signature protocols. In particular,

the scheme proposed by Chaum relies on RSA signatures as follows. Let us assume that Alice produces a

message M and wishes Bob to sign it, bur without knowing anything about M. If (N, e) and (N, d) are

respectively the Bob's public key and his private one, then Alice can determine a random number r so that

gcd(r, N) = 1 and transmit to Bob an hidden version M' of the message M, properly “blinded” by using the

random number r so that:

M' = re M mod N. (1)

Bob has no way of determining any kind of information about M from M’ but, as requested, signs it by

returning the blind signature S' to Alice, defined as:

S' = (M')d mod N = rM

d mod N (2)

Since S'=r Md mod N, Alice can determine the valid RSA signature S of M by calculating:

S = S' r-1

mod N (3)

and hence obtaining a signature for M that is impossible to be generated by Alice on her own. The

security of the above scheme is guaranteed by the inherent difficulty of performing factoring and root

extraction on large numbers. The signature scheme is ensured to be definitely “blind” by the random

nature of r, that does not allow the signer to acquire any information about the original message M even if

it is able to resolve the aforementioned factoring and root extraction problems.

Blind signatures are also able to break the association between the blind signed message and a later clear

text version that can be subject to following verification, by providing unlinkability between the two

versions, that can reveal extremely useful when anonymity is required. Accordingly such schemes have

been widely used for the implementation of crypto-based services like untraceable electronic money,

anonymous voting, and unlinkable credentials/attributes, achieving a kind of optimal balance between

individual accountability and identity protection.

6

Designated Verifier Signature Schemes

The designated verifier signature concept has been at first presented in (Jakobsson, M., Sako, K., &

Impagliazzo, R., 1996) as a mechanism for convincing only a specific verifier about the authenticity of a

signature by associating it to a unique signer. The verifier is unable to transfer the conviction to a third

party so that, only the designated verifier (or the set of designated verifiers), who is chosen in advance by

the signer, can really assert that the signature is valid. Furthermore, the verification mechanism is not

interactive since the signer does participate in any verification activity. This mechanism, by combining an

inherent authentication facility with off-the-record messages easily allows the implementation of

authenticated, private communication channels between two parties.

A designated signature scheme providing message recovery features has been introduced in (Nyberg, K.,

& Rueppel, R. A., 1993), allowing simultaneous message recovery and signature verification at the

recipient side. Instead, in this work we will use a more efficient strong designated verifier signature

scheme proposed in (Yang, F. Y., & Liao, C. M., 2010), according to which, when the sender needs to

communicate with the designated verifier, it generates a Diffe-Hellman Key Yx = g

xy mod p in order to

encrypt the target message. Upon receiving such message, the designated verifier computes a decryption

key X-y = g

-xymod p, that can be used to recover the target message and verify its validity. In detail,

according to the traditional Alice-Bob secure communication scenario, when generating the signature for

a message m, Alice chooses a random number t from Zq*, by using the public key Y of the designated

verifier Bob and its private key x to generate the Diffie-Hellman key Yx = g

xy mod p (where y is the Bob’s

private key). It then computes the message authentication code MAC=H(m||t) and r =(m||t) YxMAC

and

sends the pair (r, MAC) to Bob, where the symbol `|| ' indicates concatenations of strings and H( ) is a one

way hash function.

In order to provide message recovery and verification, upon receiving the (r, MAC) pair from Alice, Bob

will use the public key X of the sender and its private key y for generating a decryption key X-y= g

-xy and

verifies the signature by calculating:

m||t = r X-yMAC

mod p and H(m||t) =? MAC (5)

if the verification is successful, Bob is convinced that the message m is a legal one, and its true source is

Alice. This scheme has been demonstrated to be very efficient in both computation and communication

respect to traditional designated verifier signature solutions.

PROVIDING SECURE CROSS-DOMAIN AUTHENTICATION

In order to address the existing systems’ vulnerabilities the user’s identity used in the cross-domain

authentication process must be strongly protected. The available inter-cloud authentication mechanisms

are known to allow identity steal by subverted or malicious relying sites or identity providers. For this

reason, the proposed mechanism guarantees the user’s anonymity throughout the whole process by using

blind signatures to protect the data exchange between the involved parties.

In order to reduce the communication cost, and maintain strong security, the proposed scheme uses the

designated verifier signature with message recovery to protect all the communication between the

involved parties. The immediate advantage is that each entity does not need to communicate with the

established session key, and sends an encrypted message directly. Once the encrypted message is received,

the receivers can use their own private key to decrypt the message. The encrypted message also has a

designated verifier signature feature, in which signatures can only be verified by a single designated

verifier, explicitly chosen by the signer.

7

To sum up, the proposed scheme achieves the following objectives:

1. When a user signs it to access an organization requiring cross-domain authentication to a third party

identity provider such organization must not expose in any way the user’s identity information;

2. When a third party cloud organization requests a user’s registration information, the entire process

should be proof against man-in-the-middle attacks and any malicious third party entity participating

to the inter-domain authentication process.

3. All the registration data exchanges should be encrypted and authenticated with strong verification of

all the involved entities.

The Generic Authentication Process

The generic Cloud authentication process is structured according to a three-layers scheme, as shown in

Fig. 2.

Fig. 2. The three levels in the authentication process

First, users connect to the cloud front-end server to eventually obtain the needed Client components (ad-

hoc applications, browser plug ins etc.), and then request the desired Cloud-based service by providing

their own identity information, to be verified by the contacted provider directly or by relying through a

third party identity management service. In any case involved cloud provider has to confirm the identity

Crypto

Processing

Module

Client

Device

Identification

Secondary

Authentication

Form Factors

Secure

Private Key

Storage

Strong

Authentication

Service

Fraud

Detection

Service

Identity

Proofing

Service

Public Key

Management

Service

Web Access

Management Key and Cert

Management Adaptive

Authentication Authentication

System

Cloud-based services

Security

Infrastructure

Client

components

8

of the user, in order to provide access to the requested services, and ensure data transfer security during

the whole negotiation process. However, the local or third party remote Security Infrastructure stores the

user's registration and authorization information that is needed by the contacted cloud organization for

verification checks and must provide them upon specific requests. This process is accomplished by the

Authentication System, which is responsible for fetching the user identification credentials from the

repository they are stored on and passing them to the requesting organization.

In typical cloud architectures, users only access the outer layer (typically through the home page or

specific web service interface) of the front-end service, and do not directly connect with the internal

components (Ohlman, B., Eriksson, A., & Rembarz, R., 2009). The communication of between the client

and the Cloud takes place via SOAP (Simple Object Access Protocol) as envisioned in (Buyya, R., Yeo,

C. S., Venugopal, S., Broberg, J., & Brandic, I., 2009) and (Subashini, S., & Kavitha, V., 2011), a

standardized communication protocol, making it simpler for the web server to extract data from an XML

database, without having to spend time formatting the page, and allowing different applications to

exchange XML data via HTTP. The same protocols can be also used for all the internal message

exchanges between all the entities interested in the cross-domain inter-cloud authentication process.

The Inter-Cloud Authentication Process

The proposed cross-domain user authentication scheme is sketched in Fig. 3. First, the user, already

registered in Cloud A organization, chooses Cloud B to sign in, according to the following procedure:

1. The user requires access to Cloud B services, by encrypting its identity. It generates a blind

message to Cloud B, and Cloud B signs the blind signature.

2. The user also sends the unblind signature message to Cloud A organization.

3. Cloud B sends the blind signature to Cloud A, and Cloud A now has both the unblind signature

message, and the blind signature one.

4. First, Cloud A unblinds the signature, and verifies whether Cloud B is a legitimate member of the

identity provider federation or not. After the verification, the user’s registration information is

encrypted by the message recovery, and Cloud A then sends the message to Cloud B.

5. Once Cloud B receives the encrypted message, it uses its private key to decrypt and verify

messages. Cloud B can now obtain the user’s identity and personal information to be used in its

authorization process.

9

Fig. 3. The authentication process

The Protocol Details

In order to describe the protocol details the following notation is used throughout the paper:

：exclusive-or operation

|| ：concatenation operation

ib ：blind factor

in ：nonce

BN ：a large number

qp, ：two large primes such that pqNB

g ：an element of *

pZ

r

：random number

AK ：the session key between a user and Cloud A

d ：a cloud's private key to be used for signature

e

：a cloud's public key to be used for verification, where

d e = 1(mod((p-1)(q-1)))

xSK ：a x ’s private key for decryption

2.removes the

blinding factor message

1.blind message

User Cloud B

Cloud A

3.blind signature

remove the blinding factor,

authenticate Cloud B,

encryption of user personal message

4.encrypted message

5.decrypt the message

10

xPK ：a x ’s public key for encryption, where xSK

x gPK

)(mESYSx ：use the symmetrical key x to encrypt a message m

)(mDSYSx ：use the symmetrical key x to decrypt a message m

)(mExPK ：use x ’s public key

xPK to encrypt a message m

)(mDxSK ：use x ’s private key

xSK to decrypt a message m

BA? ：determine whether A and B are equal or not

(.)h ：a one-way hash function

MAC ：message authentication code

According to the schemes sketched in Fig. 2 and Fig. 3, we design a new cross-organization

authentication method, allowing the authorized transfer of users’ identification data from a Cloud

organization to another one, in order to avoid the proliferation of identities associated to each single user.

We use the characteristics of blind signatures to support user's verification on the registering provider by

also protecting the user’s identity. The whole process is sketched in Fig. 4.

Step 1: The user chooses a website, and selects a registration identity newID , a random number r and

computes it into 1C ,

newIDrC 1

The user calculates the blinded message B as follows:

B

e

i NbrhB mod)(

After this, the user sends the message ),( 1 BC to Cloud B.

The user uses the symmetrical key AK to encrypt a random number r , registration identity

newID ,

and the unblind factor 1

ib to parameter 2C

)(1

2

inewK bIDrESYSC

A

and then sends 2C to Cloud A.

Step 2: After receiving the message sent by the user, Cloud B signs a blind signature B

Bi

d

B

de

i

Nbrh

NbrhB

mod)(

mod))((

and sends the signature B to Cloud A.

Step 3: When Cloud A receives the messages 2C and B sent by user and Cloud B, respectively, it then

computes:

)()( 2

1CDSYSbIDr

AKinew

11

Cloud A then uses the unblind factor bi-1

to calculate the blind signature B

Bii

d

Bi

Nbbrh

NbBB

mod)(

mod

1

1

and verifies the correctness as follows:

B

e NBrh mod?)(

If the above equation does not hold, the connection is terminated; otherwise, Cloud A verifies

whether Cloud B exists in federation and hence is authorized in relying the authentication process.

If Cloud B is legal, Cloud A then calculates the MAC, which includes the user’s originally

registered details m in Cloud A, and a random number r, and generates nonce ni as follows:

)( inrmhMAC

Cloud A uses Cloud B’s public key PKB, its own private key SKA, and MAC in order to encrypt the

message m,r, and ni into C3 as follows:

pPKnrmCMACSK

BiA mod)(3

and then sends C3 and MAC to Cloud B.

Step 4: Once Cloud B receives the message sent by Cloud A, Cloud B uses Cloud A’s public key

PKA and its own private key SKB to decrypt the received message as follows.

pPKCnrmMACSK

AiB mod)( 3

And then verify the correctness

MACnrmh i ?)(

If the above equation does not hold, the connection is terminated; otherwise, Cloud B gets the

user’s registration message m, and can compute the registration identity IDnew

rCIDnew 1

12

Fig. 4. The protocol details

3.1 (r IDnew bi-1

) = DSYSKA (C2 )

3.2 B = ¢B ×bi-1 modNB = h(r)dbi ×bi

-1 modNB

3.3 h(r)?BemodNB

3.4 MAC = h(m r ni )

3.5 C3 = (m r ni )PKBSKA ×MAC mod p

1.1 C1 = rÅ IDnew

1.2 B = h(r)bie modNB

2C

BC ,1

MACC ,3

1.3 C2 = ESYSKA (r IDnew bi-1)

2.1 ¢B = (h(r)bie)d modNB = h(r)dbi modNB

User Cloud B Cloud A

4.1 (m r ni ) = C3 ×PKA-SKB×MAC mod p

4.2 h(m r ni )?MAC

4.3 IDnew = C1 Å r

B

13

SECURITY ANALYSIS

In this section, we analyze the security of our scheme and discuss the possible attacks against it.

According to the general security practices and the most common services requirements, the most

important security issues related to cloud access are authentication and anonymity. Therefore, we will

focus on these issues in order to analyze how the most common kind of menaces can affect the proposed

scheme, by studying its robustness and tolerance against them.

Authentication

The main vulnerability of the OpenID system resides in the fact that an attacker can provide a service

supplier with the user's identity, and then obtain the user’s personal information without authentication. In

our proposed protocol, the user must inform the Cloud where to register a new identity, and give the

unblind factor 1

ib . When Cloud B signs the blind signature and sends the message to Cloud A, Cloud A

will verify the message eBrh ?)( . Only by passing this authentication phase the user can assert its identity

in Cloud B. That is, only if Cloud A can authenticate Cloud B; otherwise, the authentication process will

be interrupted.

Anonymity

Before Cloud A authenticates Cloud B, Cloud B does not know the registration identity newID (since

newID is protected by1C )( 1 newIDrC ) of the user. Cloud B will sign the blind

message B

e

i NbrhB mod)( into a blind signature Bi

d NbrhB mod)( . This lets Cloud A know that

the user has really been to this website. When Cloud B is authenticated by Cloud A, Cloud B can only get

r to decrypt1C . In this way, our scheme totally guarantees user’s anonymity.

Robustness against Man-in-the-middle Attacks

2C is protected by the public key APK , and only Cloud A can decrypt it. Therefore, attackers cannot

perform man-in-the-middle attacks on 2C . Moreover, the security of

3C is based on the difficulty of the

Discrete Logarithm Problem (DLP), and the session key is built by Diffie-Hellman key exchange

mechanism )( ABA SKSKSK

B gPK . However, an attacker must have both the public and private keys to

decrypt 3C , which is otherwise impossible to decrypt.

Robustness against Server Spoofing Attacks

Sometimes attackers can pretend to be a server so as to manipulate the sensitive data of legal users. In our

scheme, this is impossible, since, if an attacker wants to pretend to be a server operating within the

federated authentication process, it must first pass the original server authentication.

On the other hand, the attacker cannot masquerade as a user to register in a legal Cloud. When a user

wants to register with a new Cloud, they need to authorize in by obtaining the original Cloud permission,

and verify whether the Cloud is authorized or not. If the Cloud does not get the authorization or is

blacklisted by the federation, then the user’s personal information will not be provided to the supplier. So

attackers cannot perform server spoofing attacks.

Robustness against Phishing Attacks

14

OpenID is also known to be vulnerable to phishing attacks (Laurie, B., 2007), where a malicious relying

entity performs redirection to a phishing website in order to catch the user’s authentication credentials.

Analogously to the aforementioned considerations concerning server spoofing attacks, an attacker cannot

pretend to be an authentication entity (and hence a recognized IdP) without passing in advance the inter-

cloud server authentication checks, so that if the involved Cloud does not get the authorization by the

federation, then the user’s credentials will not be provided in any way to the phishing site.

Robustness against Eavesdropping Attacks

In eavesdropping attacks, an attacker listens to the communication channel between the client and server,

and then tries to obtain the user’s private message (personal information, password, etc). Our scheme is

robust against these kind of attacks due to the following reasons:

1. The communication messages are protected by 1C and

2C using the exclusive or

operation )( 1 newIDrC , and symmetric key )(1

2

inewK bIDrESYSC

A. Therefore, an

attacker cannot easily eavesdrop on messages between the user and the Cloud.

2. In our scheme, we use the existing public keys to encrypt

messages )mod)(( 3 pPKnrmCMACSK

BiA . When the receiver receives the message,

certification and verification of the correctness of the messages are performed at the same time.

Therefore, a malicious attacker cannot easily eavesdrop on messages between users and Clouds.

Once the message is received, the receiver can decrypt and verify the correctness at the same

time )mod)(( 3 pPKCnrmMACSK

AiB and ))?)(( MACnrmh i .

CONCLUSION

A new security scheme has been proposed as a flexible solution inter-cloud authentication within a cross-

domain framework. It should be highly useful in easing the diffusion and deployment of federated digital

identity management infrastructures in the cloud arena, thus overcoming most of the security and privacy

worries, which negatively influence the establishment of cross-authentication agreements between

different organizations.

The adoption of this scheme has the immediate effect of reducing the number of perceivable

authentications when accessing resources on different cloud organizations, letting users to transparently

log-in to many different cloud services provided by multiple organizations that recognize identities issued

by other domains within a federation, by using a single “home” identity, and hence greatly enhancing the

quality of usage experience in multi-domain federated environments.

Great efforts have been invested in trying to improve the communication efficiency, while ensuring

anonymity of user’s own data and secure interaction among the various components, resulting in the

enhancement of the robustness of the whole system. By introducing such scheme, malicious entities are

no more able to implement most of the known attacks based on man-in-the-middle, server spoofing and

eavesdropping practices.

The authors believe that this cross-domain application could shed new light onto existing problems in the

field, as well as discover new threats that can emerge with the interaction of new solutions that can be

adopted in more interdisciplinary areas.

ACKNOWLEDGEMENT

15

This research was supported by the Ministry of Science and Technology, Taiwan, R.O.C., under contract

number MOST103-2632-E-324-001-MY3, MOST 103-2221-E-324 -023 and MOST 103-2622-E-212-

009 -CC2.

REFERENCES

Armando A., Carbone R., Compagna L., Cuéllar J., Pellegrino G., Sorniotti A. (2013), An authentication

flaw in browser-based Single Sign-On protocols: Impact and remediations, Computers & Security, 33,

41-58.

Barth, A., Jackson, C., & Mitchell, J. C. (2008, October). Robust defenses for cross-site request forgery.

In Proceedings of the 15th ACM conference on Computer and communications security (pp. 75-88).

ACM.

Brands, S. (2007). The Identity Corner-The problem (s) with OpenID. URL

http://www.untrusted.ca/cache/openid.html.

Buyya, R., Yeo, C. S., Venugopal, S., Broberg, J., & Brandic, I. (2009). Cloud computing and emerging

IT platforms: Vision, hype, and reality for delivering computing as the 5th utility. Future Generation

computer systems, 25(6), 599-616.

Chang, C. C., & Lee, J. S. (2006). An anonymous voting mechanism based on the key exchange protocol.

Computers & Security, 25(4), 307-314.

Chaum, D. (1982, August). Blind Signatures for Untraceable Payments. In Crypto (Vol. 82, pp. 199-203).

Chen, Y. Y., Jan, J. K., & Chen, C. L. (2004). The design of a secure anonymous Internet voting system.

Computers & Security, 23(4), 330-337.

Diffie, W., & Hellman, M. (1976). New directions in cryptography. IEEE Transactions on Information

Theory, 22(6), 644-654.

Jakobsson, M., Sako, K., & Impagliazzo, R. (1996). Designated verifier proofs and their applications. In

Advances in Cryptology—EUROCRYPT’96, pp. 143-154. Springer Berlin Heidelberg.

R. Khan, J. Ylitalo, and A. Ahmed, (2011). OpenID authentication as a service in OpenStack, 2011 7th

International Conference on Information Assurance and Security (IAS), 5-8 Dec. 2011, Melaka,

PP.372-377.

Kurdi H., Al-Anazi Campbell A., C., A. Faries A. (2014), A combinatorial optimization algorithm for

multiple cloud service composition, Computers & Electrical Engineering,

doi:10.1016/j.compeleceng.2014.11.002.

Laurie B. (2007), OpenID: Phishing Heaven, Available from: http://www.links.org/?p=187,

(Accessed on March 2015).

Miller, J. (2006). Yadis specification. Notes, 6, 3.

16

Nyberg, K., & Rueppel, R. A. (1993, December). A new signature scheme based on the DSA giving

message recovery. In Proceedings of the 1st ACM conference on Computer and communications security,

pp. 58-61.

Ohlman, B., Eriksson, A., & Rembarz, R. (2009, June). What networking of information can do for cloud

computing. WETICE'09. 18th IEEE International Workshops on Enabling Technologies: Infrastructures

for Collaborative Enterprises, pp. 78-83.

OpenID Foundation. (2005). Attribute Exchange Security Alert. URL

http://openid.net/2011/05/05/attribute-exchange-security-alert/

Recordon, D., & Reed, D. (2006, November). OpenID 2.0: a platform for user-centric identity

management. In Proceedings of the second ACM workshop on Digital identity management, pp. 11-16.

Sovis, P., Kohlar, F., & Schwenk, J. (2010, October). Security Analysis of OpenID. Proceedings of the

Securing Electronic Business Processes–Highlights of the Information Security Solutions Europe 2010

Conference, pp. 329-340.

Subashini, S., & Kavitha, V. (2011). A survey on security issues in service delivery models of cloud

computing. Journal of Network and Computer Applications, 34(1), 1-11.

Sun, S. T., Hawkey, K., & Beznosov, K. (2012). Systematically breaking and fixing OpenID security:

Formal analysis, semi-automated empirical evaluation, and practical countermeasures. Computers &

Security, 31(4), 465-483.

Svantesson, D., & Clarke, R. (2010). Privacy and consumer risks in cloud computing. Computer Law &

Security Review, 26(4), 391-397.

Tormo G. D., Mármol F. G., Pérez G. M. (2014), Towards the integration of reputation management in

OpenID, Computer Standards & Interfaces, 36(3), 438-453.

Van Delft, B., & Oostdijk, M. (2010). A security analysis of OpenID. Proceedings of the 2nd IFIP WG 11.6

Working Conference on Policies and Research in Identity Management (IDMAN'10), pp. 73-84.

Yang, F. Y., & Liao, C. M. (2010). A provably secure and efficient strong designated verifier signature

scheme. International Journal of Network Security, 10(3), 220-224.