1 Introduction

In the cloud computing era, users connecting to the Internet gain not only unlimited information of various kinds, but also an increment of computational power and data storage spaces. For example, commercial cloud computing platforms such as Amazon, Google AppEngine and Microsoft Azure are a natural fit to remedy the lack of local resources. This advantage is particularly appealing to mobile devices. Although the power of smart phones or smart devices increases rapidly in recent years, mobile applications always demand much more resources for improved interactivity of better user experience. According to a report from Smith’s Point Analytics (2013) released in 2013, mobile cloud services platforms are projected to grow over the next four years from US$579 million to a staggering US$4.4 billion in 2017. As we can easily see, our world is shifting into the mobilesphere every day. Companies, especially small and medium enterprises (SME), may find more opportunities to connect with their customers in an incredibly cost-effective way through mobile connectivity. They can easily gain more benefits from mobile cloud computing (MCC) technologies, especially for business-to-customer (B2C) business. For example, they only need to provide subscription registration and user interface for the services by outsourcing the core computation part to the cloud. This will greatly reduce the setup and running cost of any SME and increase their chance of success.

Fig. 1
figure 1

The architecture of our access-control system

Full size image

The envisioned success of MCC technologies relies not only on the mature network and communication infrastructure, but also upon the security mechanisms over these infrastructures. We can imagine if the security challenges are not well addressed, MCC would not be widely adopted. For example, a company using “Pay-as-you-go” model needs to have some kind of access control mechanisms to ensure that all connecting users have paid for their service.

In this article, we introduce a secure and cost-effective access control protocol in mobile cloud computing, which is specifically designed for SMEs providing B2C services. In our architecture, a SME providing various services to mobile users (e.g. online game, speed dating, online survey, etc.) outsources its core computation to a cloud. The SME is only responsible for user registration (and billing matters) while the access control part can be totally outsourced to the cloud. It is illustrated in Fig. 1. Within this architecture, our protocol possesses the following nice features:

  1. 1.

    The user database never leaves the SME. It does not need to share with the cloud any data about its subscribed users. This can highly protect the user privacy and increase user confidence.

  2. 2.

    There is no communication required between the SME and the cloud during user authentication process. Users directly deal with the cloud for the access. In this way, the SME does not need to rent a large bandwidth communication channel between its local server and the cloud. Furthermore, it is not necessary either to equip with a high-end and expensive security infrastructure such as a powerful firewall to detect and prevent DDoS attacks. All security measurements can be done on the cloud side.

  3. 3.

    Anyone who has stolen a mobile device but without knowing the corresponding password cannot gain access to the system. It can further withstand dictionary and phishing attacks against user password.

  4. 4.

    Our system allows the SME to provide fine-grained access control. Instead of specifying a set of particular users for the access, the SME can define an access policy (e.g. LEVEL=VIP AND COUNTRY=US). This can greatly increase the flexibility and reduce a lot of work load by the SME.

Paper organization. The remainder of this paper is organized as follows. In Sect. 2, we will further review some existing access control techniques and explain why they are not suitable for SME in mobile cloud computing environment before giving the details of our protocol. Section 3 describes the preliminaries required by our protocol. The details of our protocol and its analysis are given in Sect. 4. Finally, Sect. 5 concludes this paper.

2 Existing access control techniques

In this section, we review some existing access control techniques, including simple username/password system, certificate with random challenge, and attribute-based certificate techniques.

Username/password system: This is the most simple (but efficient) access control mechanism. Each user has a unique (registered) username with a corresponding password. As a simple but representing example, the server stores the username and the hash (the output of a crytographic hash function such as SHA-1) of the password. (A crytographic hash function has the properties of one-wayness and collision resistance. One-wayness means given the output, it is computational infeasible to find its input. Collision resistance means that it is computational infeasible to find two different inputs such that their outputs are the same.) When the user types his/her username and password, the server computes the hash of the password and compares the one stored in its database. This mechanism is simple and efficient. However, it cannot withstand pre-computed dictionary attacks or rainbow table attacks (on the server side) and phishing attacks (on the user side). For the former attack (on the server side), an adversary checks the hash of the password stored on the server (we suppose the server is compromised) against its pre-computed table. If this pre-computed table is large enough, the checking should be efficient. Although the attack may be defended by using salted hash (the hash of password plus a salted public value is stored instead of the hash of password), if the salted value is known (unfortunately it is usually the case if the adversary has broken into the server!), the adversary can still efficiently launch the aforementioned attack. For the latter attack, it is especially concerned in mobile devices, as it is easier to launch such an attack on mobile device than on normal PC computer. Once the adversary captures the username and password, it can easily pretend the victim to access the system and the user may have no way to detect it before any significant information loss occurs.

Certificate with random challenge: A digital certificate is a signature generated by a trusted party, called Certificate Authority (CA), on a user public key and his/her identification information (such as name, email, organization, etc.). This certificate and the corresponding secret key can be used in a simple authentication protocol: A user first sends the certificate to the cloud. The cloud verifies the certificate. If it is valid, it sends a random number (called the random challenge) to the user. The user signs this number using his secret key. The cloud then uses the public key (extracted from the certificate) to verify the user’s signature. This classical authentication protocol can withstand phishing and replay attacks as the random number is different in each round.

However, the above techniques (username/password and certificate with random challenge) both require a three-party authentication if the user database is kept in the SME side. Since the above techniques can only prove that the user interacting with the cloud is the claimed one, it cannot let the cloud know whether this user has the right to access or use the service provided by the SME. The cloud needs to send an inquiry to the SME to ask for the status or access level of this user. It seems to be a normal action and it may not cause too much trouble to the SME. Nevertheless, if there are many users who login to the cloud at the same time, even though the cloud can handle it (as we assume the cloud should have a larger bandwidth for many users to access at the same time), the SME may not be able to respond concurrently (since the SME is not supposed to equip with a very powerful server to handle this situation). The same thing happens if the cloud is being DDoS attacked. In order to provide a normal service in any circumstance, the SME may need to have a strong firewall and large bandwidth connecting to the cloud. That will definitely increase the running cost of the SME. In order to resolve this shortcoming, an attribute-based access control is preferred instead of the classical digital certificate. We briefly introduce it below.

Attribute-based access control: An attribute-based access control is a variant of attribute-based cryptography (Sahai and Waters 2005; Goyal et al. 2006; Bethencourt et al. 2007; Ostrovsky et al. 2007; Pirretti et al. 2010; Waters 2011; Lewko and Waters 2011a, b; Maji et al. 2011; Sahai et al. 2012; Lewko and Waters 2012; Rouselakis and Waters 2013; Garg et al. 2013; Hohenberger and Waters 2013; Chen et al. 2014; Hohenberger and Waters 2014; Li et al. 2014, 2015; Rouselakis and Waters 2015; Wei et al. 2015; Liu et al. 2015; Wu et al. 2015; Xhafa et al. 2014). In attribute-based cryptography, users are represented by attribute. For example, a user may have the attributes SEX=MALE; DEPT=PHY SICS; STATUS=STUDENT; UNIVERSITY=ABC UNI instead of his/her real name! In each round of authentication, there is a specific policy (for example, only MALE AND STUDENT are allowed to use the service). Those users whose attributes satisfy the policy can go through the authentication. In the case of access control, each user has a secret key associated with his/her attributes. The user uses the attribute-associated secret key to interact with the cloud. In this way, the cloud does not need to have any communication with the SME, as the interaction between the cloud and the user can determine whether this user has the access right. This is a great improvement over the above-mentioned classical systems. Nevertheless, all attribute-based cryptographic primitives are anonymous. Privacy is good in some sense, but maybe not preferred in some cases. For instance, the SME may want to have an event log and have a detailed statistical information about each user’s habit for using its services. Anonymous access control does not provide the way for tracing any user. Thus in many practical scenarios, anonymous access is not the preferred way. Furthermore, attribute-based cryptographic primitives usually require complicated and inefficient mathematical algorithms such as a number of exponentiations and pairings. Some may even require to use composite order group for pairing operation which is only of theoretical interest but contains no practical value.

From the above discussion, we can see that it seems none of the existing technologies can provide a satisfactory access control mechanism in the mobile cloud computing paradigm. We summarize the comparison among these technologies and our proposed mechanism in Table 1.

Table 1 Comparisons among different mechanisms
Full size table

3 Preliminaries

In this section, we shall briefly describe the necessary preliminaries required by our protocol.

3.1 Existentially unforgeable digital signatures

In the public-key setting, a digital signature scheme consists of three algorithms (KeyGen, Sign, Ver) associated with key generation, signing and verification, respectively. These three algorithms are defined as follows:

  1. 1.

    KeyGen: This algorithm produces a private–public key pair (sk, pk). On input a security parameter \(\lambda \), this algorithm produces a private signing key sk and a public verification key pk.

  2. 2.

    Sign: This algorithm produces digital signatures. On input a private key sk and a message m, this algorithm generates a signature \(\sigma \) on m.

  3. 3.

    Verify: This algorithm verifies the validity of digital signatures. On input a message-signature pair \((m,\sigma )\) and a public key pk, this algorithm outputs “1” if \(\sigma \) is a valid signature, or “0” otherwise.

The correctness of a digital signature scheme requires that \(Verify(m,pk,Sign(m, sk))=1\) for any pair (sk, pk) output by KeyGen.

The standard security requirement of digital signatures is existential unforgeability against adaptive chosen message attacks (Vaudenay 2005). This is defined by a game between the challenger and a probabilistic polynomial-time (PPT) adversary. A PPT adversary is allowed to adaptively make signing queries to a signing oracle which outputs a valid signature on the message chosen by the adversary. After all queries are made, let \(M=\{m_i\}\) be the set of messages chosen by the adversary. The adversary outputs a pair \((m^*,\sigma ^*)\) and breaks the existential unforeability of a signature scheme if \(Verify(m^*,\sigma ^*,pk)=1\) and \(m^* \notin M\). A digital signature scheme is existentially unforgeable if no PPT adversary can win the game with a non-negligible probability. Examples of existentially unforgeable digital signature schemes include Schnorr signature (Schnorr 1989), BLS signature (Boneh et al. 2004) and BB signatures (Boneh and Boyen 2008)

3.2 Cryptographic hash function

A hash function maps a message of arbitrary size to a digest of fixed size. Hash function is the cornerstone of modern cryptography. A cryptographic hash function, denoted by H, must possess the following properties:

  1. 1.

    Pre-image resistance: Given a hash value h, no PPT algorithm can find a message m satisfying \(h = H(m)\) with a non-negligible probability.

  2. 2.

    Second pre-image resistance: Given a message \(m_1\), no PPT algorithm can find a different message \(m_2\) satisfying \(H(m_1) = H(m_2)\) with a non-negligible probability.

  3. 3.

    Collision resistance: No PPT algorithm can find a pair of different messages \((m_1, m_2)\) satisfying \(H(m_1) = H(m_2)\) with a non-negligible probability.

3.3 Complexity assumptions

Let G be a multiplicative group with prime order p, and g be the generator. Given an element \(X\in G\), let \(x=DL_gX\) denote the discrete logarithm of X on the base g in the group G, i.e., \(X=g^x\).

The computational Diffie-Hellman problem is that given (G, g, p) and two random group elements \(X, Y \in G\), output \(Z\in G \) such that

$$\begin{aligned} DL_gZ=DL_gX \cdot DL_gY. \end{aligned}$$

The computational Diffie-Hellman assumption states that no PPT algorithm can solve the computational Diffie-Hellman problem with a non-negligible probability.

4 A secure and cost-effective access control protocol

Our protocol deploys the concept of attribute-based system to avoid any communication between the cloud and the SME during user authentication stage. The user database is kept inside the SME to achieve the highest data protection of users while it can also withstand pre-computed dictionary attacks or rainbow table attacks on the server side and phishing attacks on the user side. It can further provide traceability to the SME.

4.1 Description of protocol

There are three stages in our protocol: Setup, User registration, and User Authentication.

Setup stage: The SME executes the Diffie-Hellman key exchange protocol with each cloud server. Namely, with a common prime order (p) group G generated by a generator g, the SME (with a secret value \(k_s \in Z_p\)) publishes \(g^{k_s}\). At the same time, the cloud (with a secret value \(k_c \in Z_p\)) also publishes \(g^{k_c}\). We assume both \(g^{k_s}\) and \(g^{k_c}\) are certified by an authority. Then the SME computes \(K = (g^{k_c})^{k_s}\) while the cloud computes \(K' = (g^{k_s})^{k_c}\). Since \(K=K'\), both sides establish a common key. The SME chooses a signing key sk and a verification key pk and also publishes pk. The cloud can then verify any signature generated by the SME using pk.

User registration stage: A user with a user name USERNAME and a set of attributes ATTB chooses a secret key usk and the corresponding public key upk, password PASSWORD and sends \(\{\mathtt{PASSWORD},upk\}\) to the SME. The SME uses its signing key sk to generate two signatures as follows:

$$\begin{aligned}&\sigma _1 = \texttt {SIGN}_{sk} \Big ( \mathtt{USERNAME} || upk ||\\&H \big ( \mathtt{PASSWORD} || PRF( K || \mathtt{USERNAME}) \big ) \Big )\\&\sigma _2 = \texttt {SIGN}_{sk} ( \mathtt{USERNAME} || \mathtt{ATTB} ). \end{aligned}$$

Here, “||” denotes concatenation of strings and H is a collision-resistance hash functions and PRF is a pseudorandom function (Goldreich et al. 1986). (Note that we can fix the length of each item. If an item is shorter than the pre-defined length, we can add some zero-padding to increase the length.)

User authentication stage: A user sends \(\sigma _1, \sigma _2\), upk, his/her attribute set ATTB and types his/her username USERNAME and password PASSWORD to the cloud. If ATTB cannot fulfill the required policy for this service, the cloud rejects the connection immediately. Otherwise, the cloud first verifies if \(\texttt {VERIFY}_{pk}(\sigma _2, \mathtt{USERNAME} ||\) \(\mathtt{ATTB})\) returns true. If yes, it further computes \(M = \mathtt{USERNAME} || upk || H \big ( \mathtt{PASSWORD} || PRF( K' || \mathtt{USERNAME}) \big )\) and verifies if \(\texttt {VERIFY}_{pk}(\sigma _1, M)\). If all verifications pass, the cloud sends a random number t to the user. The user computes a signature \(\sigma _s = \texttt {SIGN}_{usk} (t)\) using his/her secret key usk and sends \(\sigma _s\) back to the cloud. The cloud verifies if \(\texttt {VERIFY}_{upk}(\sigma _s, t)\). If it returns true, the cloud accepts the user. In practice, all communications between the user and the cloud should be protected under SSL connection. The flowchat of this stage is shown in Fig. 2. The frequently used notations of our protocol are also summarized in Table 2.

Fig. 2
figure 2

User authentication stage

Full size image
Table 2 Frequently used notations
Full size table

4.2 Extension

There are some extensions that our protocol can further include.

One-time password: In order to further increase the security protection, there is an option to add a one-time password (OTP) to the protocol. An OTP can be sent to the mobile device through SMS and the user is required to type the OTP during the authentication. In this case, the mobile number of the user should be added to the message signed by \(\sigma _1\) and sent together with other information to the cloud by the user.

User revocation: User revocation can be implemented by having a user revocation list given by the SME to the cloud. The cloud first checks against the revocation list for the communicating user (with his/her username). If the username is on the list, the cloud rejects the connection immediately.

4.3 Security analysis

We briefly describe how our proposed protocol can defend against the following attacks and achieve some security features:

Dictionary attack: Systems are exposed to dictionary attacks if they store the hash (or salted hash) of users’ password. In our protocol, the hash (or salted hash) of password is never stored on any server (including the SME server or the cloud server). Even though the adversary can somehow extract \(\sigma _1\) (that contains the salted hash of the password), since the adversary does not know K or \(K{^\prime }\) which are known to the cloud and the SME only (due to the computational Diffie-Hellman assumption), it is difficult to launch the attack. Moreoever, the “salt” value is an output of a pseudorandom function which takes the username as the input. In other words, the “salt” value is different for every user. It further increases the difficulty for dictionary attacks.

Phishing attack: Even the adversary uses some phishing technique to re-direct the user to another site to capture the username and password, the adversary still cannot pretend the user to authenticate with the cloud since it does not know the secret key usk inside the device. As long as the signature scheme is existentially unforgeable, the adversary can neither extract the secret key nor forge a signature even it has observed a polynomial number of signatures generated.

Authenticity: Users with attributes not satisfying the policy cannot gain access to the cloud. It can be seen from the fact that the attributes are included in \(\sigma _2\) which is a signature signed by the SME. As long as the signature scheme is existentially unforgeable, the user has no way to modify the attribute list.

Traceability: Username is sent to the cloud by the user during the authentication stage. If a user uses a different username rather than the one included in \(\sigma _1\), the verification will not pass. Thus the cloud can maintain a log of usernames who have been accessed for the service.

4.4 Performance evaluation

Our protocol is very efficient. The mobile device only needs to compute one exponentiation during the registration stage, and one signature generation (if Schnorr signature scheme (Schnorr 1989) is used, it only takes one exponentiation) during the authentication stage. Using the simulation data by jPBC (Caro 2015), a mobile device (HTC Desire HD A9191, Android 2.2) requires 71.5 ms to execute an exponentiation if elliptic curve (supersingular curve \(y^2 = x^3 + x\)) is used with 160 bits group order (equivalent to 1024 bits RSA security). On the SME server, it only needs to generate two signatures during the registration stage and the cloud only needs to verify three signatures during the authentication stage. The running time of these algorithms by the SME and the cloud should be regarded as negligible.

5 Conclusion

In this article, we have suggested a fuzzy access control protocol for SME providing B2C services on mobile cloud computing platform. Our protocol allows the SME to be offline during user authentication stage, which can greatly reduce the running cost of SME as it does not need to have a strong firewall or large bandwidth connecting with the cloud. Our protocol can further withstand common attacks such as dictionary attack on server or phishing attack on client. Traceability is provided to the SME and it is very efficient to mobile devices. We believe it is practical to be implemented in the commercial world.