A Privacy-Preserving Attribute-Based Authentication ...

IEEE TRANSACTIONS ON MOBILE COMPUTING, VOL. 13, NO. 9, SEPTEMBER 2014

1927

A Privacy-Preserving Attribute-Based Authentication System for Mobile Health Networks Linke Guo, Student Member, IEEE, Chi Zhang, Member, IEEE, Jinyuan Sun, Member, IEEE, and Yuguang Fang, Fellow, IEEE Abstract—Electronic healthcare (eHealth) systems have replaced paper-based medical systems due to the attractive features such as universal accessibility, high accuracy, and low cost. As a major component of eHealth systems, mobile healthcare (mHealth) applies mobile devices, such as smartphones and tablets, to enable patient-to-physician and patient-to-patient communications for better healthcare and quality of life (QoL). Unfortunately, patients’ concerns on potential leakage of personal health records (PHRs) is the biggest stumbling block. In current eHealth/mHealth networks, patients’ medical records are usually associated with a set of attributes like existing symptoms and undergoing treatments based on the information collected from portable devices. To guarantee the authenticity of those attributes, PHRs should be verifiable. However, due to the linkability between identities and PHRs, existing mHealth systems fail to preserve patient identity privacy while providing medical services. To solve this problem, we propose a decentralized system that leverages users’ verifiable attributes to authenticate each other while preserving attribute and identity privacy. Moreover, we design authentication strategies with progressive privacy requirements in different interactions among participating entities. Finally, we have thoroughly evaluated the security and computational overheads for our proposed schemes via extensive simulations and experiments. Index Terms—Authentication, non-interactive zero-knowledge proof, non-interactive witness-indistinguishable, homomorphic encryption

1

I NTRODUCTION

W

IDELY deployed electronic healthcare (eHealth) systems have improved people’s daily life compared with traditional paper-based systems for its extraordinary advantages, such as higher efficiency, better accuracy, and broader availability. Also, mobile healthcare (mHealth) systems leverage portable devices to facilitate the usage of eHealth systems, which enables patients to efficiently and effectively collect personal health data and obtain better medical services. For most mHealth systems, patients use sensors, implantable medical devices (IMDs), and mobile phones to collect personal health records (PHRs), then send medical data to the designated healthcare infrastructure to obtain physicians’ diagnosis via wireless interfaces. According to a recent report [1], there are more than 77% patients and 70% physicians who want to get involved

• L. Guo and Y. Fang are with the Department of Electrical and Computer Engineering, University of Florida, Gainesville, FL 32611 USA. E-mail: {blackglk, fang}@ece.ufl.edu. • C. Zhang is with the School of Information Science and Technology, University of Science and Technology of China, Hefei 230026, China. E-mail: [email protected]. • J. Sun is with the Department of Electrical Engineering and Computer Science, University of Tennessee, Knoxville, TN 37996 USA. E-mail: [email protected]. Manuscript received 6 June 2012; revised 10 June 2013; accepted 14 June 2013. Date of publication 15 July 2013; date of current version 22 July 2014. For information on obtaining reprints of this article, please send e-mail to: [email protected], and reference the Digital Object Identifier below. Digital Object Identifier 10.1109/TMC.2013.84

with mHealth systems by using their own mobile devices. However, although the Health Insurance Portability and Accountability Act (HIPAA) has been established for years to regulate PHR related operations, the privacy concern is still arguably the major barrier that hinders the deployment of mHealth systems based on centralized infrastructures (hospitals or medical clinics) [2]. In particular to patients’ sensitive PHRs, they are associated with highly-private information, such as social security number, address, and date of birth, all of which can be easily used by attackers for impersonating real patients and/or launching identity theft attacks [3], [4]. Even worse, several medical records theft and stolen incidents [5] have been reported recently, in which attackers steal and publish patient health information to a third party and/or over the Internet. According to a recent survey [6], researchers estimate the economic impact of medical identity theft in the United States at 41.3 billion dollars per annum. Moreover, more than 78% of participants in [7] worry about the leakage and misuse of their personal information and health condition, so that they fear to use of eHealth/mHealth systems. Especially to mHealth systems, the potential privacy leakage from mobile devices is also another crucial concern for patients, and it has not been discussed clearly so far. For most eHealth/mHealth systems, physicians periodically upload their observations and diagnosis to a particular storage, in which protected health information (PHI) is seamlessly bound to the real identity of a specific patient. When physicians are authorized, they can

c 2013 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. 1536-1233 See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.

1928


easily obtain both the identity information and the corresponding diseases of a patient. To some extent, patients may be reluctant to contact a doctor or a medical facility based on their real identities, instead, they may be more willing to get medical attention by showing just a certificate for their diseases, medical history or other necessary attributes, rather than exposing real identities. This possible solution leads us to consider the possibility of separating multiple attributes from a single identity, and allows users to mutually authenticate each other using their attributes. On the one hand, if the authentication process takes place on a centralized infrastructure as current mHealth systems, even if the identity is isolated from the corresponding attributes, the centralized infrastructure may still leak the correlation between attributes and identity during verification process. On the other hand, if users (patients, physicians or caregivers) directly communicate with each other without the use of a centralized infrastructure, the privacy issues related to attributes can be preserved. However, purely relying on distributed authentication cannot fulfill the requirement in terms of the verifiability and authenticity of isolated attributes. In a word, existing mHealth systems lack the ability to preserve the privacy and the verifiability of the corresponding attributes simultaneously. Taking a step further, patients face these security breaches and authentic verification risks when they share the same medical situations and want to talk with each other. These kinds of concerns become the biggest stumbling blocks that impede patients from participating in mHealth systems [8]. Similar to physicians, in existing mHealth systems, those who want to offer medical advice fail to prove their professional expertise without leaking their identities, due to the possible impersonation attacks and the corresponding lawsuits related to digital certificates lost/stolen in the cyberspace [9]. Thus, there is an urgent need for designing a framework, in which users can authenticate each other using verifiable attributes while keeping the linkage between their attributes and identities undisclosed. Related Works: To deal with the potential risks of privacy exposure, several eHealth systems [10]–[12] enable patients to encrypt their PHRs before storing it on the central storage. Although the encrypted PHR prohibits the centralized facility from obtaining the private information, it still faces the problem of data verifiability. Since most of these PHRs are vital, physicians cannot accept or utilize the records without an official verification. On the other hand, it seems easy to implement the verification process for the eHealth systems due to the centralized management. However, in this case it is obvious that we must directly show the record itself and the corresponding identity to get the PHR verified, all of which bring the possibility of security breaches to patients’ records. In recent research works on social networks, several possible solutions have been proposed to utilize attributes for authentication without revealing attributes themselves. Similarly, their proposed systems lack the functionality of verifiability. The most relevant work is Li. et al. [13] which considers a privacy-preserving personal profile matching scheme for mobile social networks, which implements secure multi-party computation based on polynomial secret

sharing. Their scheme is fully distributed, where users share their attributes among a group of valid users using Shamir’s secret sharing scheme. Also, in [14], a secure friend discovery scheme is designed based on secure dot product protocol by using homomorphic encryption. Multiple papers [15]–[17] address the problem of secure private set intersection (PSI), which is related to the highest privacy level in our proposed system. However, none of them considers the verifiability of the private set, which is the major difference compared with our scheme. More specifically, their schemes deviate from our design goals due to the fact that attributes in the eHealth systems are crucial for patients and needed to be verified before taking any further action. For the centralized model, Eagle and Pentland [18] describe social serendipity to perform matching in mobile social networks, which purely relies on the centralized server. It faces the security breaches of privacy leakage and collusion attacks. In conclusion, none of the above systems meets the verifiability and privacy preservation simultaneously. In this paper, we will use the cryptographic tool: the non-interactive zero-knowledge proof which was first introduced by by Blum et al. [19]. Our scheme employs the non-interactive proof system for bilinear pairing in [20] which has been used for several applications in [21]–[23]. Another technique we want to use is the attribute-based encryption (ABE). Although there are several works on ABE discussing the authentication schemes in [24]–[26], we cannot apply them to authenticate strangers. In most ABE schemes, the key distribution center is responsible for distributing public/private key pairs based on each individual’s attributes and corresponding structure. If they are in the same attribute group, they may mutually authenticate each other. However, in our proposed application scenario, patients need to prove to physicians or hospitals that they have a specific disease. Since patients do not share identical attributes with physicians, they cannot get verified using the corresponding private keys. Furthermore, patients do not want to expose their sensitive attributes and values for verification, which is also the main reason that the public key cryptosystem will not work for our application scenario. Our Contributions: Our major contributions are as follows: •

•

•

•

We design a distributed authentication system in mHealth networks, where patients/physicians use their verifiable attributes to authenticate each other before communication. Our attribute-based authentication system is able to simultaneously provide the privacy protection and verifiability of patients/physicians’ verified attributes. Based on different application scenarios, we provide progressive privacy levels corresponding to patients/physicians’ increasing privacy requirements during their interactions. Extensive simulations and experiments are conducted on different platforms to verify the performance of our schemes in terms of security, efficiency, and feasibility.

GUO ET AL.: PRIVACY-PRESERVING ATTRIBUTE-BASED AUTHENTICATION SYSTEM FOR MOBILE HEALTH NETWORKS

1929

The remainder of this paper is organized as follows. Section 2 introduces preliminary knowledge of some cryptographic techniques that we use in our system. We describe the system and adversary model in Section 3, along with the security objective. The proposed scheme is presented in detail in Section 4, followed by the performance analysis in Section 5. Finally, Section 6 concludes the paper.

2

P RELIMINARIES

2.1 Bilinear Pairing Bilinear pairing operations are performed on elliptic curves [27]. Let G1 and G2 be multiplicative groups of the same prime order p, respectively. Discrete logarithm problem (DLP) is assumed to be hard in both G1 and G2 . Let g denote a random generator of G1 and e:G1 × G1 → G2 denote a bilinear map constructed by modified Weil or Tate pairing with the following properties: Bilinear: e(ga , gb ) = e(g, g)ab , ∀g ∈ G1 and ∀a, b ∈ Z∗p . In particular, Z∗p = {x | 1 ≤ x ≤ p − 1}. 2) Non-degenerate: ∃g ∈ G1 such that e(g, g) = 1. 3) Computable: there exists an efficient algorithm to compute e(g, g), ∀g ∈ G1 . Bilinear pairing is the basic operation in identitybased cryptosystems, and the non-interactive witness-indistinguishable (NIWI) and zero-knowledge proofs (NIZK), all of which are used as the fundamental building blocks in our scheme. 1)

2.2 NIWI and NIZK Proof We apply part of the non-interactive proof system in [20], which gives a formal definition for both non-interactive witness-indistinguishable and zero-knowledge proof. We define R as a computable ternary relation. Given a tuple (crs, n, w) ∈ R, we call crs as the common reference string, n as the statement that we need to prove and w the witness. Note we also use L to denote the language consisting of statements in R. Suppose R consists of three polynomialtime algorithms (K, P , V ), where K is crs generation algorithm, P and V are prover and verifier, respectively. P takes a tuple (crs, n, w) as input and output a proof π, while V (crs, π, n) will output 1 if the proof is acceptable and 0 if not. The proof system (K, P , V ) should satisfy completeness and soundness properties, where completeness denotes if the statement is true, an honest verifier is convinced of this fact by an honest prover, and soundness shows that if the statement is false, and cheating prover can convince the honest verifier that is true with a negligible probability. For NIWI, we require no adversary can distinguish the real crs and simulated crs, while adversaries cannot distinguish which witness the prover uses. For zero-knowledge, we require no verifier obtains additional information other than the fact that the statement is true.

3

S YSTEM M ODEL

3.1 System Overview We first give a brief overview to our proposed system. Our main design goal is to establish an authentication system in mHealth networks, which leverages the verifiable

Fig. 1. System model.

attributes to enable the authentication between physicians and patients or a pair of patients without compromising each other’s privacy. Apart from schemes that purely rely on the identity, we first define the attribute-based authentication system which simultaneously meets the needs of verifiability and privacy preservation in mHealth networks. As shown in Fig. 1, our system mainly consists of a trust authority (TA) which is responsible for key distribution for users (physicians and patients), a semi-trusted registration center (RC) mainly used to generate and issue credential based on users’ attributes. To some extent, TA performs as a government health administration which should be fully trusted, while RC can be hospitals or clinics with certain qualification certified by TA. During the protocol run, RC also checks physicians’ professional expertise and issues the corresponding credentials to physicians. In Fig. 1, users in different colors represent distinct patients in mHealth networks in a distributed manner. Patients use portable devices, such as smartphones, monitoring sensors, or IMD to collect their PHRs. Then, they directly transmit it to RC and receive certain diagnosis or undergoing treatments using their mobile devices. Here, we assume that RC verifies the authenticity of patients’ PHRs and issues the corresponding credentials representing attributes in the PHRs. Each patient uses pre-assigned pseudonyms to anonymously prove their attributes in order to obtain medical services, or communicate with each other without disclosing real identity. Similar to patients, physicians can prove their professional skills without showing their private information. After the proof and authentication process, a verifier is convinced that the designated user has the claimed attribute. Users may start communications based on the verification results, e.g., patient-to-physician diagnosis, or patient-to-patient discussions. For mobile devices used in the proposed systems, we simply assume users stay in the transmission range of each other when they want to initiate the communications.

3.2 Security Objectives 3.2.1 Security Requirements and Assumptions Our main security objective is to preserve the privacy of each user’s identity and attributes. First, we assume that a user’s attribute set can uniquely identify a particular user, such that we cannot reveal user’s attributes in plaintext form during the protocol run. Also, since users use credentials of attributes to authenticate each other, we require

1930


the credential of each attribute should be kept undisclosed. Second, our system should be secure under tracing attacks launched by adversaries, which means the information used for verification from the same user in different queries should remain indistinguishable. Otherwise, it is easy for an adversary, or even a benign user to trace one particular user. Besides, according to the restrictions and laws, like the Health Insurance Portability and Accountability Act (HIPPA), we forbid physicians and hospitals to distribute PHRs to any unauthorized personnel. In terms of privacy concerns, patients use verified PHRs to communicate with physicians and/or patients without using real identities in order to avoid being traced.

3.2.2 Privacy Levels We define four levels of privacy to deal with different application scenarios during the interactions in mHealth networks. Note that our four privacy levels have the progressive property in the sense that a higher privacy level discloses less information but incurs more computation costs, and lower privacy level leaks more details but may be efficient, respectively. However, all of the privacy levels in our framework provides anonymity and untraceability for users in the system. Privacy Level 0 (PL-0): We are defining the most intuitive privacy level which mostly happens between patients and physicians. For example, doctors may want to convince anonymous patients that what they said or suggested is true, but do not want to reveal their credentials or identities during the authentication process. Otherwise, adversaries may impersonate doctors by using their credentials. On the other hand, patients also prefer to use pseudonyms to show their attribute sets of a particular disease, in which physicians can take turns to verify that the patient indeed has the diseases rather than stealing the remedy. Therefore, PL-0 requires everyone verify the validity of the attribute credentials without compromising the privacy of users (physicians or patients). Privacy Level 1 (PL-1): Other than verifying the validity of the corresponding attribute credentials, we take a step further to check the value of users’ attribute. To some extent, the value of each attribute is a more severe privacy related issue rather than verifiable attributes. For example, to obtain information that Dr. Frank is with the department of internal medicine in Shands hospital at University of Florida will leak less privacy than to know he is a cardiologist in that hospital. Here cardiologist is a specific value of an attribute on “affiliation”. In addition to verifying the validity of attributes, we need the verification of the value of an attribute in the authentication process in what follows. In PL-1, users are not concerned about revealing several kinds of information which is meaningless if it is not associated with real identities. For instance, an AIDS assistant organization provides services but requires a patient’s attribute value to meet the organization’s requirements. Apparently, few patients want to expose the real identities to obtain the services, while PL-1 satisfies the corresponding conditions and could guarantee the organization can only verify patients’ credentials and values of attributes other than identifying real identities.

Privacy Level 2 (PL-2): In what follows, we consider patient-to-patient communication in mHealth networks. Patients may want to share some information concerning their diseases to patients who have the same symptoms, but strictly prohibit other patients from knowing in detail [28]. Once they learn each other’s identical attribute values, they can directly communicate and share certain information. Thus, we need to provide privacy-preserving authentication schemes based on patients’ identical attribute values. Rather than the possibility of leaking several “meaningless” information from the patient side in PL-1, PL-2 requires patients only reveal the same attribute values to the other users and disclose nothing if two compared attribute values are not identical, in the sense that patients can authenticate each other based on their same verified attribute values while maintaining other attribute values undisclosed. When the protocol ends, patient A and B will only mutually learn the intersection set between them: MAB = SA∗ SB∗ , where ∗ ⊆ S denotes the subset of whole attribute set of A. Note SA A that if attributes are Boolean data type, such as the gender, there is no way to prevent the verifier from learning the prover’s values of those attributes even if the verification process fails. Thus, we take advantage of several common data types other than Boolean types, i.e., strings and integers. Privacy Level 3 (PL-3): For higher security and privacy requirements, PL-3 requires all of patients’ attribute values used for authentication should not be revealed to anyone else. Different from the scenario presented in PL-2, we require that two patients may only know the cardinality of the intersection set of shared attributes, which is also defined as similarity score. Taking patient A and B as an example, both A and B only learn the similarity score: mAB = |SA∗ SB∗ |, where |S | denotes the cardinality of set S . Apparently, we cannot compare each attribute value one by one. Otherwise, it turns out to be the same privacy level as in PL-2. Instead, we design a verifiable attribute set comparison protocol for PL-3 between patients, which only returns the cardinality of intersection set and keeps each of attribute values undisclosed.

3.3 Adversary Model We consider various types of adversaries which may launch passive or active attacks to our system. For active attacks, adversaries can launch impersonation attacks to compromise the privacy of both physicians and patients. Also, an adversary may eavesdrop the communication channels or modify and inject bogus data during the transmissions. On the other hand, it is possible for any kind of user (malicious or benign) to trace back users’ real identities, in the sense that attackers may launch active attacks to the identity based on the attribute verification and comparison results. So, we also need to guarantee the untraceability for any user during the protocol run. Furthermore, we are concerned with the collusion attack among a group of malicious users or even between RC and malicious users. Since the semi-trusted RC, which is curious but honest, has all credentials it issues, the collusion attack will largely deteriorate the privacy level if it cannot be thwarted. However, we will not consider the possibility of sharing


TABLE 1 Main Notations

secret with others because this type of active attacks cannot be prevented in almost all security systems.

4

P ROPOSED S CHEME

In this section, we introduce our framework for privacypreserving authentication in detail. Based on the assumptions and definitions in the previous sections, we first give a formal non-interactive proof system used throughout this paper and then present the cases corresponding to progressive privacy levels.

4.1 Non-Interactive Proof System We implement the non-interactive proof system proposed by Groth and Sahai [20], which is an efficient zeroknowledge proof system for bilinear groups. However, their work is based on general cases for bilinear pairing without considering the scenarios in mHealth system. Without loss of generality, we briefly review their scheme in advance. For the ease of reading, we refer Table 1 for our major notations and parameters. 4.1.1 Setup As in the previous section, assume that we have a bilinear map e:G1 × G1 → G2 . With entry-wise multiplication, we can get the Zp -modules M1 = G31 , in which we define another bilinear map eˆ:M1 × M1 → M2 . Note our system is based on the decision linear assumption introduced by Boneh et al. in [29] stating that given three random generators f , h, g ∈ G1 and f r , hs , gt , it is hard to test t = r+s. In the main design of our system, we use the module M2 = G62 given by entry-wise multiplication. The symmetric bilinear map eˆ6 :G31 × G31 → G62 is given by ⎛⎛ ⎞ ⎛ ⎞⎞ ⎛ ⎞ a x e(a, x) e(a, y)e(b, x) e(a, z)e(c, x) e(b, y) e(b, z)e(c, y)⎠ eˆ6 ⎝⎝b⎠ , ⎝y⎠⎠ → ⎝ 0 c z 0 0 e(c, z) Lemma 1 ([20]). Define a map μ:Z9p → M2 , ∀u1 , u2 , u3 ∈ M1 , ∃ρ11 , ρ12 , . . . , ρ33 ∈ Z9p and t1 , . . . , tH ∈ Zp , such that 3 3 H ρij = 1, where ρij = h=1 th ηhij and i=1 j=1 eˆ 6 (ui , uj ) ηhij ∈ Zp .

1931

For perfect soundness of the NIWI and NIZK proof, the common reference string and simulated reference strings must be computationally indistinguishable, so we also have μ(ηh ) = 1 for all ηh ∈ Z9p and ηhij ∈ ηh performs as the basis for generating the kernel of μ.

4.1.2 Proof Generation We will use NIWI and NIZK together and/or separately based on different scenarios in our framework. Note that NIWI proof attempts to convince that the witnesses in the statement are indistinguishable, where the verifier or adversaries cannot locate which witness (prover) corresponds to the statement, while NIZK proof implies that the statement can be verified without exposing any other information. We denote the credential of A’s unique attribute as x ∈ G1 , while there could be other variables in the bilinear paring, i.e., y ∈ G1 . Suppose x and y form an equation e(x, y) = T, where T ∈ G2 . User A uses elements in M1 and chooses random numbers in Zp to generate two commitments Com(x) and Com(y). Then, A can make the corresponding NIWI or NIZK proof π based on Com(x) and Com(y). In our scheme, patients/physicians are given the authority to generate unique proofs and commitments for verification. 4.1.3 Verification TA has a bulletin board for publishing the common reference string (crs) used for every member in the system to verify the given proofs. Given proof πi , Com(x), Com(y), public parameter ui and the statement e(x, y) = T that we are concerned with, we can set up the following verification equation for a verifier to publicly verify the corresponding statements or equations: ⎛ ⎞ 3 111 (1) eˆ6 (ui , πi ). eˆ6 (Com(xq ), Com(yq )) = ⎝0 1 1 ⎠ 0 0 T i=1 If the check passes, the variables x and y satisfy the statement while ensuring that the verifier learns nothing about x and y.

4.2 Privacy Level 0 (PL-0) In PL-0, we are facing the problem of verifying the validity of corresponding credentials issued by RC without exposing them. Without loss of generality, we hereby list the following steps which are implemented in all of our privacy levels. 4.2.1 Setup TA is responsible for generating system parameters and distributing corresponding public/private key pairs to the valid users in the system. We list the possible procedures in the system initiation, although several steps will not be directly implemented in this scenario. In the system setup, TA generates system parameters (include crs) and assigns the ID-based public/private key pairs for each user in the system, and then TA may go offline. For ease of presentation, we assume that there is a secure channel between TA and any user in the system, like SSL or TSL, which can be achieved by any public key cryptosystems. The key generation procedures are as follows [27]: 1) Input the

1932


security parameter ξ to the system and output parameter tuple (p, G1 , G2 , e, g, H). 2) Randomly select a domain master secret ς ∈ Z∗p and calculate the domain public key as Ppub = gς . Here, we use multiplicative notation in this paper to keep consistency. TA publishes the domain parameters (p, G1 , G2 , e, g, H, Ppub ) and maintain ς confidential, where H(·) is defined as before H(·):{0, 1}∗ → G1 , and g is a random generator of G1 . Given a specific public ID ∈ {0, 1}l , the public/private key (pkID /skID ) pair is H(ID)/H(ID)ς , which are distributed by TA during the initiation process. We also assign a number of collision-resistant pseudonyms for anonymous communications. Taking user A as an example, it will be given a set of pseudonyms, PS A = {PSκA |1 κ |PS A |}. Each pseudonym of A is given a set of secret keys as skPS A = {skPS κA } = {H(PS κA )ςA ∈ G1 |1 κ |PS A |} corresponding to the set of pseudonyms. Note that every party can query TA for public/private key pairs of its pseudonym set and ςA ∈ Z∗p is the master secret selected by TA for A.

4.2.2 CRS Generation The above generation process outputs a set of parameters (p, G1 , G2 , e, g). TA randomly picks α, β, ru , sv ← Zp , sets f = gα , h = gβ , and generates ui ∈ M1 , which are u1 : = (f , 1, g), u2 : = (1, h, g) and u3 : = (f ru , hsv , gtw ), where tw = ru + sv . TA then sets the crs as (p, G1 , G2 , e, M1 , M2 , eˆ, g, u1 , u2 , u3 , η1 , η2 , η3 ) and publishes it on the bulletin board for users to verify proofs. 4.2.3 Credential Issuance RC applies the parameters selected by TA, picks a random integer x˜ ı ∈ Z∗p for a specific class of attributes, where ı could represents age, affiliation, gender, etc. Once it successfully verifies the specific attributes (via the diagnosis of physicians for patients or certification authority for physicians), it computes the credential v˜ ı = gx˜ ı ∈ G1 and e(g, g) ∈ G2 . The public key tuple for the verification is (g, v˜ ı , e(g, g)), while the secret/sign key held by RC is x˜ ı corresponding to different attributes. Intuitively, users can show their validity by presenting v˜ ı . However, we cannot directly reveal the credential v˜ to the public verifiers, which may incur the impersonation attack when adversaries use credentials to show their validity on specific attributes. For example, to prove user A is a valid physician, we implement the certified signature scheme in [22], [30] for the verification of valid v˜ . RC randomly picks group elements ˆ ) as the authorˆ zˆ ∈ G1 , and publishes the tuple (fˆ , h, fˆ , h, ity key to verify v˜ , where = e(fˆ , zˆ ) ∈ G2 and zˆ is a secret key for RC. Then, RC picks a random number rˆ ∈ Zp and computes (a, b): = (fˆ −ˆr , (hˆ · v˜ )rˆ · zˆ ). Given v˜ , one is able to verify the valid credential by checking e(a, hˆ · v˜ )e(fˆ , b) = . 4.2.4 NIWI Proof Generation As we can see, there are only two variables that we want to hide, v˜ and b. The original schemes [22], [30] is not concerned about the revealing of the credential v˜ , while we need to keep those checking processes continuing without exposing the plaintext value of v˜ . In this case, A uses the parameters from the published bulletin board u1 , u2 , u3 ∈

M1 and chooses r11 , r12 , r13 , r21 , r22 , r23 ∈ Zp to commit v˜ r r r and b as follows, Com(hˆ · v˜ ): = c0 : = (1, 1, hˆ · v˜ )u111 u212 u313 r r r and Com(b): = d0 : = (1, 1, (hˆ · v˜ )rˆ · zˆ )u121 u222 u323 . Apart from this, A also generates a set of NIWI proofs, πi : = (1, 1, fˆ −ˆr )r1i (1, 1, fˆ )r2i .

(2)

Then, A sends the packet c0 , d0 , π1 , π2 , π3 to the public domain for verification.

4.2.5 Public Verification For privacy concerns, user A may not want to expose his/her real identity or credentials on the third party or the public domain. As a result, given the public parameters crs ˆ ), users can verify the validity of corresponding and (fˆ , h, credentials. Similar to the bilinear map eˆ6 :G31 × G31 → G62 , we define another bilinear map eˆ9 :G31 × G31 → G92 : ⎛⎛ ⎞ ⎛ ⎞⎞ ⎛ ⎞ a x e(a, x) e(a, y) e(a, z) eˆ9 ⎝⎝b⎠ , ⎝y⎠⎠ → ⎝e(b, x) e(b, y) e(b, z)⎠ . c z e(c, x) e(c, y) e(c, z) Users verify the validity of the corresponding credential by checking the equality of the following equation, ⎞ ⎛ ⎛ ⎞⎞ ⎛ ⎛ ⎞⎞ ⎛ 1 1 3 11 1 ? eˆ9 (ui , πi ). eˆ9 ⎝c0 , ⎝ 1 ⎠⎠ · eˆ9 ⎝d0 , ⎝1⎠⎠ = ⎝1 1 1 ⎠ ˆf −ˆr ˆf 1 1 i=1 Lemma 2 ([20]). Let M1 , M2 be Zp -modules, for all r ∈ Zp , u, u , v ∈ M1 , we have eˆ(ur u , v) = eˆ(u, v)r eˆ(u , v). Accordingly, the left-hand side of its equation can be derived as follows, ⎛⎛ r11 +ru r13 ⎞ ⎛ ⎞⎞ f 1 LHS = eˆ9 ⎝⎝hr12 +sv r13 ⎠ , ⎝ 1 ⎠⎠ ˆv h˜ fˆ −ˆr ⎛⎛ r +r r ⎞ ⎛ ⎞⎞ 1 f 11 u 13 ⎝ ⎝ ˆ hr12 +sv r13 ⎠ , ⎝ 1 ⎠⎠ · e9 gr˙ fˆ −ˆr ⎛⎛ r21 +ru ⎞ ⎛ ⎞⎞ ⎛⎛ r +r ⎞ ⎛ ⎞⎞ f 1 1 f 21 u · eˆ9 ⎝⎝hr22 +sv ⎠ , ⎝1⎠⎠ · eˆ9 ⎝⎝hr22 +sv ⎠ , ⎝1⎠⎠ ˆ v)rˆ zˆ gr¨ (h˜ fˆ fˆ Due to the page limit, we only show the verification of the intersection of row 3 and column 3 of the corresponding matrix, ˆ v, fˆ −ˆr )e(gr˙ , fˆ −ˆr )e((h˜ ˆ v)rˆ , fˆ )e(ˆz, f )e(gr˙ , f ) LHS33 = e(h˜ = e(ˆz, f )e(g, f )r¨−ˆrr˙ where r˙ = r11 + r12 + tw r13 and r¨ = r21 + r22 + tw r23 . Meanwhile, the right-hand side of the equation can be derived as follows, RHS33 = e(g, f −ˆrr11 +r21 )e(g, f −ˆrr12 +r22 )e(g, f −ˆrr13 +r23 ) = e(g, f )−ˆrr˙+¨r . It is obvious that if the provided credential is verified, the above two equations will be equal, which implies that the attribute is verified by RC while keeping it undisclosed. Note that patients’ attributes also can be verified using PL-0.


4.3 Privacy Level 1 (PL-1) In most cases, patients have different values on a specific attribute, such as the length of disease history, the size of cancer tumor or the remedy, which are highly concerned with privacy issues and easily be identified. In PL-1, we consider the scenario where there is a server to verify the value of the corresponding attributes of patients but without requiring patients’ real identities. Based on different values on an attribute, RC issues distinct certificates to different users. Here we define the certificate as a specific credential corresponding to the value of an attribute. Note that certificates for the same attribute value on different real identities are the same. For the privacy reason, patients would not turn in the certificate that RC has issued on a specific value of an attribute for verification. 4.3.1 Certificate Issuance We consider an asymmetric setting between the server1 S and an individual patient. We will use Boneh-Boyen signature scheme [29] to sign the attribute value, which is shown to be secure under weak chosen message attacks based on the q-Strong Diffie-Hellman (q-SDH) assumption. RC continues to use x˜ ı to sign each specific value of corresponding attribute. We assume the value of attribute in our system could be represented as a message mı.j ∈ Zp , where ı denotes the general classification of attributes and j is the specific value of those attribute, as Stage II represents the “degree of severity of AIDS” (a kind of an attribute). To prevent malicious attacks from patients (discussed in later sections), we add a random number ε ∈ Zp \{−(˜xı + mı.j )} selected by RC for the purpose of update for the same attribute and security of verification. Given the message mı.j along with the secret key x˜ ı and ε, RC outputs a certificate σı.j : = g1/(˜xı +mı.j +ε) ∈ G1 . Besides, RC issues the server ε : = g(mı.j +ε) for further verifiS an additional certificate δı.j cation. Note that RC periodically updates σı.j for patients ε for the server S. accompanied with δı.j 4.3.2 NIWI Proof Generation and Verification We also utilize the proof generation process in PL-0 used to verify the validity of the attribute. Apart from that, we also need to generate the NIWI proofs for proving the equality of values of a specific attribute. Before the NIWI proof process begins, a patient (which could be seen as a prover) needs to obtain the additional certificate from the server side to generate commitments and proofs. Suppose S accepts the query from patient A, 1. 2.

PS κA → S:EpkS (mı.j ), τ1 , SIG(EpkS (mı.j ||τ1 ) ε ), τ , SIG(E ε S → PS κA :EpkPS κ (δı.j 2 pkPS κ (δı.j ||τ2 ) A

A

where E(·) is the ID-based encryption and SIG denotes the efficient ID-based signature scheme [31] which could be verified by the corresponding public ID. Note that τ represents the timestamp used to prevent reply attacks. The following NIWI proof process includes three steps: committing to the variables, generating proof and verification. 1. We use server to represent possible physicians or organizations that need to verify patients attribute values.

1933

Committing to the variables: We list the validity verification equation in PL-0 to denote that both of the equations must be simultaneously satisfied and verified by the verifier: e(a, hˆ · v˜ ı )e(fˆ , b) =

e(σı.j , v˜ ı · g

(mı.j +ε)

)e(g

−1

(3)

, g) = 1.

(4)

ε from the server S, Given the additional certificate δı.j patients need to use v˜ ı and σı.j to prove the equation e(σı.j , v˜ ı · g(mı.j +ε) )e(g−1 , g) = 1, which implies that the value of the attribute that he/she holds is the same as that on the server side. Based on the NIWI proof system, the server would not be able to get the plaintext of σı.j , which perfectly hides the certificate privacy of patients. If the equation is not satisfied, the patient learns nothing about the correct additional credential from S while the server S cannot obtain the certificate σı.j . For the NIWI proof generation, patient A chooses the ui ∈ M1 from the published crs to commit those variables as follows, taking the second equation as an example. A first chooses the elements u1 , u2 , u3 ∈ M1 from crs and randomly selects r1 , r2 , r3 , r1 , r2 , r3 ← Zp . r Then, A computes Com(σı.j ): = c1 = (1, 1, σı.j )ui i = (f r1 +r3 ru , hr2 +r3 sv , σı.j gr1 +r2 +r3 (ru +sv ) ), and A also commits to the other variable as Com(˜vı · g(mı.j +ε) ): = d1 = (1, 1, v˜ ı · r

g(mı.j +ε) )ui i = (f r1 +r3 ru , hr2 +r3 sv , v˜ ı · g(mı.j +ε)+r1 +r2 +r3 (ru +sv ) ). Generating NIWI proof: For patient A, it needs to generate the NIWI proof π i by using the parameters in crs and the commitments. Given the kernel vectors of μ6 in crs, η1 : = (0, 1, 0, −1, 0, 0, 0, 0, 0), η2 : = (0, 0, 1, 0, 0, 0, −1, 0, 0), η3 : = (0, 0, 0, 0, 0, 1, 0, −1, 0), A randomly selects t1 , t2 , t3 ∈ Zp to generate the NIWI proofs as follows: πi =

3

3

uj

h=1 th ηhij

r

(1, 1, σı.j )ri d1i

j=1

Verification: When patient A wants to verify himself that he has the corresponding credential meeting the requirements of the server, A sends the packet c1 , d1 , π 1 , π 2 , π 3 to the server. We can modify the equation (4) to e(σı.j , v˜ ı · g(mı.j +ε) ) = e(g, g), where T = e(g, g) is a known factor. After obtaining proofs along with commitments, the server can verify the validity of the user’s attribute according to equation (1): ⎛⎛ ⎞⎞ ⎞ ⎛ f r1 +r3 ru f r1 +r3 ru ⎜ ⎜ ⎟⎟ LHS = eˆ6 ⎝⎝hr2 +r3 sv ⎠ , ⎝ (5) hr2 +r3 sv ⎠⎠ (m +ε)+ ı.j σı.j g v˜ ı · g where = r1 + r2 + r3 (ru + sv ) and denotes the r1 + r2 + r3 (ru + sv ), respectively. The server S then checks the right-hand side as follows, 3 i=1

eˆ6 (ui , π i ) =

3

r eˆ6 (ui , (1, 1, σı.j )ri d1i )

i=1

= eˆ6

3 i=1

r ui i , (1, 1, σı.j )

eˆ6

3 i=1

r u i i , d1

1934


⎞ ⎛ ⎞⎞ f r1 +r3 ru 1 ⎟ ⎜⎜ ⎟ = eˆ6 ⎝⎝hr2 +r3 sv ⎠ , ⎝ 1 ⎠⎠ σı.j g ⎛ ⎛⎛ ⎞⎞ ⎞ f r1 +r3 ru f r1 +r3 ru ⎜ ⎜ ⎟⎟ · eˆ6 ⎝⎝hr2 +r3 sv ⎠ , ⎝ hr2 +r3 sv ⎠⎠ g v˜ ı · g(mı.j +ε)+ ⎛⎛

Note that we omit several terms in the proof π i since we have 3i=1 3j=1 eˆ6 (ui , uj )ρij = 1 according to Lemma 1. By directly applying the bilinear operation to the above equations, we can easily check that all the entries satisfy the equalities in the equation (5) except the last one in the matrix. However, we verify the result in the row 3 and column 3 of the corresponding matrix by expanding all the pairing results as follows,

LHS33 = e(σı.j g , v˜ ı · g(mı.j +ε)+ )

= e(g, g)

1 + x˜ ı +mı.j +ε

(˜xı +mı.j +ε+ )

1+(˜xı +mı.j +ε)+ x˜ +m

= e(g, g)

ı

ı.j +ε

+

,

(6)

and according to equation (1),

RHS33 = T · e(g , σı.j )e(g , v˜ ı · g(mı.j +ε)+ ) 1+ x˜ +m

= e(g, g)

ı

ı.j +ε

+(˜xı +mı.j +ε+ )

(7)

After the verification process, the server S is able to convince itself that patient A holds the attribute that is satisfied S’s requirement: the value of the attribute provided by A is the same as S’s. Thus, S can give the access privilege or other rights based on the verification results. Note that PL-1 also works well under the symmetric scenario where the privacy of the attribute value is not needed, and patients or physicians can mutually verify their corresponding specifications. Our implementation in PL-1 specifies a special case of asymmetric structure where the value of the attribute is crucial for the application.

4.4 Privacy Level 2 (PL-2) We have formally described our scheme on PL-0 and PL-1, where patients allow to leak several information to the server or physicians. For computational efficiency, we leverage the server side to share an additional attribute certificate for the verification process in PL-0 and PL-1. However, according to the privacy definition in PL-2, patients cannot disclose any private information to a stranger or even a so-called trusted server if they are not sure whether they share the same attribute values as theirs. The major difference between previous two privacy levels and PL-2 is that PL-2 hides attributes from the verifier when the verifier does not have those attributes and the corresponding values. The most possible application for PL-2 exists in patient-to-patient communications, where patients with same attributes and values may want to initiate discussions using mobile devices. However, what patients most concerned about is that they do not want to reveal the identity and disease detail to patients who do not have the same attribute values. We can apply pseudonyms as a solution to addressing the exposure of identity privacy, and design the scheme to protect other privacy concerns.

4.4.1 Initiation Contrary to PL-1, we do not make additional certificate ε on the server side. Instead, the communication parδı.j ties in PL-2 are in a symmetric structure in the sense that both patients are able to obtain the same comparison results when the protocol terminates. RC issues valid user certificates corresponding to the specific attribute as σ ı.j : = g1/(˜xı +mı.j ) . Two patients will mutually authenticate each other using the NIWI proofs to show they have a valid credential and verifiable value on the attribute, 1. 2.

PS κA → PS κB :cı.j , dı.j , π1 , π2 , π3 , PS κB → PS κA :cı.j , dı.j , π1 , π2 , π3 .

where cı.j denotes Com(σ ı.j ), and dı.j represents Com(˜vı · gmı.j ), respectively. Two users can mutually verify each other using the NIWI proofs based on equation (3) and (4).

4.4.2 Equality NIWI Proof Generation The above authentication process can verify the validity of the corresponding attributes and values, but it does not imply any relationship between the attribute and identities. For the case of checking the intersection set of the compared attributes, we require the two patients to send the random parameters to each other, which brings out a new series of NIWI proofs π˙ i to verify the equality of two committed values. Suppose A uses si , si ∈ Zp to commit σ ı.j and v˜ ı · gmı.j , respectively. Also, B chooses ti , ti ∈ Zp to generate cı.j and dı.j . For generating equality NIWI proofs π˙ i , B sends back to A the random parameter set {ti }. Then, A computes the following results and sends them to B, π˙ i =

3

3

uj

h=1 th ηhij

(1, 1, σ ı.j )ti (dı.j )si

j=1

Note that sharing the random parameter set {ti } will not reveal the corresponding credentials. Although A is able t

to generate a set (1, 1, 1)ui i , it is infeasible to recover the credential from dı.j and the above value set.

4.4.3 Verification The verification process is more or less similar to that in PL-1. When A sends the equality NIWI proofs π˙ to B, B checks the equality of the following equation: ⎛ ⎞ 3 111 (8) eˆ6 (ui , π˙ i ). eˆ6 (cı.j , dı.j ) = ⎝0 1 1 ⎠ 0 0 T i=1 xı +mB ı.j xı +mA ı.j

B which implies that e(g, g) = e(g, g), where mA ı.j and mı.j are the attribute values of A and B on the same attribute. If the above equation is satisfied, B is convinced the equality of two attribute values. Otherwise, B will find the inequality of the equation (8), which shows that the attributes of A and B are not identical. Apart from this, both A and B learn nothing about credentials and attribute values from each other. B can further verify itself to A reversely. Here, we only show the verification process for one single attribute value. It is obvious that we can apply this scheme in verifying a set of attributes by repeating the same process. When


the protocol ends, both patients will only learn the identical attribute values that they have. However, for a single user, it will incur more pairing invocations than PL-1 for one attribute.

4.5 Privacy Level 3 (PL-3) PL-3 requires that two patients can mutually obtain the cardinality of the intersection of attribute set (also defined as similarity score) without learning the detail of each identical attribute value. Compared to PL-2, patients even would not want to disclose the attribute value to the one that has the same value as theirs. They only can accept the comparison results on the number of identical attribute values in the intersection set. Here, we simply assume the weight of each attribute value is the same for general perspective. PL-3 not only relies on the NIWI proofs introduced in the previous subsection, but also applies the NIZK proofs to prove the equality of the corresponding ciphertexts and commitments without exposing the real plaintext value. Then, each patient implements homomorphic encryption on the received ciphertext. Finally, both patients are able to decrypt the values, where 1 denotes the same attributes, and otherwise represents different attribute values between two users. By randomly rearranging the sequence of the homomorphic results, no one is able to obtain the detail about which two attributes are identical when we compare a large set of attributes. The NIWI proof generation and verification processes for the two involved patients are the same in the first step of PL-2. Patient A wants to compare a set of attributes SA∗ , and ∗ we further assume all mA ı.j ∈ SA have been verified using the technique listed in the previous subsection. We make the following modification for PL-3. 4.5.1 Parameter Distribution In general, PL-3 needs to perform operations on the encrypted values instead of commitments, because we cannot perform the operations over the committed values, such as comparison, addition, multiplication, etc. The reason that we choose selective-tag encryption [32] in our scheme is that it has an encrypted form which perfectly matches the commitment scheme used in the NIWI proof. We briefly review the selective-tag encryption scheme. First, TA assigns a tuple pk: = (f , h, k, l) ∈ G41 as a public key for A, and distributes the private key (χ, ψ) to her where f = gχ , h = gψ . Then, patient A chooses random numbers r, s ∈ Zp and select a public tag t to encrypt a message m as r s E (m): = (f , h , gr+s m, (gt k)r , (gt l)s ). The decryption can be r s done by computing m = gr+s m · (f )−1/χ (h )−1/ψ . In the previous privacy levels, users apply parameters on crs to generate and verify the corresponding proofs. However, in order to provide attribute privacy in PL-3, we need to change the parameters used before. Since we use the same parameters f , h ∈ G1 to commit and encrypt the certificate, we require the TA to bind signatures on every parameter issued to users, such that verifier can first verify the parameters that the prover has used, and then check the authenticity of the corresponding attributes. Before the protocol run, TA randomly picks χ, ψ, ru , sv ←

1935

Z∗p and assigns a set of public/private keys to each individual user corresponding to pseudonyms in what follows. Set f = gχ , h = gψ as the public key, and generate the ui ∈ M1 , which are u1 : = (f , 1, g), u2 : = (1, h, g) and ru sv u3 : = (f , h , gtw ), where tw = ru + sv . Then, TA distributes the message f , h, ui , (f ||h||ui ) to valid patients, where (·) denotes the TA’s signature on a particular message. If patients want to mutually authenticate each other under PL-3, they send the above packet to each other for proof verification.

4.5.2 NIZK Proof Generation The generation process of NIZK is similar to NIWI in [22], where we commit to the exponential of the generator g. We first show the statements that we need to prove. Given A) : = the ciphertext of encrypted certificate of A as E (σı.j re

se

A , (gt k)re , (gt l)se ). = (f , h , gre +se σı.j (X1 , X2 , X3 , X4 , X5 ) A) : = According to the previous subsections, Com(σı.j r1 +r3 ru

(C1 , C2 , C3 ) = (f r0 = r1 − re and s0 statements that need proving the equality encrypted value, r0

r2 +r3 sv

A gr1 +r2 +r3 (ru +sv ) ). Setting ,h , σı.j = r2 − se , we have the following to be simultaneously satisfied for of the committed value and the

ru

s0

sv

−1 ϕ r3 ϕ r3 ϕ = 1 ∧ (C−1 1 X1 ) f (f ) = 1 ∧ (C2 X2 ) h (h ) = 1 ϕ r0 +s0 ∧(C−1 (f 3 X3 ) g

ru +sv r 3

) =1

(9)

where we cannot disclose ϕ, r0 , s0 , r3 to the verifier and we need to prove the above equations given the ciphertexts and the commitments. Note that ∧ denotes and. To generate the commitments, we randomly select two numbers θ, ζ ∈ Zp and add one more universal ζ parameter u: = uθ1 u2 onto the message that TA distributes before the protocol run, which has the form as f , h, ui , u, (f ||h||ui ||u) . Taking second equation in Eq. (9) as an example, we need to commit to the exponentials ν ν ν ν ϕ, r0 , t as C1 = uϕ u11 u22 , C2 = ur0 u11 u22 and C3 = t ν1 ν2 u u1 u2 ,where νi ∈ Zp are random numbers. Then, A can generate NIZK proof as follows, ru

νi νi νi π¨ i = (1, 1, C−1 1 X1 ) (1, 1, f ) (1, 1, f ) A to B, user Since A has already sent the commitment of σı.j −1 B is able to compute Ci Xi after A delivers the ciphertexts.

4.5.3 Verification First of all, A sends the packet f , h, ui , u, (f ||h||ui ||u) to B for verification. If the verification of passes, B is convinced that the parameters are valid from TA. To check the equality of certificates in commitments and ciphertexts, the verifier checks the equality of the following equations. Due to page limit, we do not present the detail of the checking process. However, the process is similar to Eq. (3), ⎛⎛ ⎞ ⎞ ⎛⎛ ⎞ ⎞ 3 2 1 1 eˆ9 ⎝⎝ 1 ⎠ , Ci ⎠ = eˆ9 ⎝⎝1⎠ , u⎠ eˆ9 (π¨ i , ui ) (10) Yi 1 i=1 i=1 ru

where Yi is the ith element in the set (C−1 1 X1 , f , f ), respectively. Patient B checks the satisfiability of all the four

1936


equations. If the check passes, B is convinced that the value in the commitment is equal to that in the ciphertext.

4.5.4 Deriving Similarity Score The similarity score between two patients is the size of identical attributes of their intersection sets. Based on the ciphertexts of certificates, patients perform homomorphic encryption on each single ciphertext and return to each other for deriving the result. Homomorphic Encryption: Our proposed scheme relies on the encryption results of selective-tag encryption which has the following properties, 1.

Multiplicative homomorphic property: E (m1 )E (m2 ) = (f r1 +r2 , hs1 +s2 , gr1 +r2 +s1 +s2 m1 · m2 ,

(gt k)r1 +r2 , (gt l)s1 +s2 ) = E (m1 · m2 ) 2.

Self blinding property:

D(E (m, r1 , s1 , t)) = D(E (m, r1 + r2 , s1 + s2 , t)). Score Derivation: We suppose both A and B mutually give a same set of attribute classes for the comparison, like O: ={affiliation, height, ages, disease,...} with a predefined order. For the verifier, it is impossible to guess out the values inside the commitment other than verifying the satisfiability of the corresponding statements. Thus, when A gives to B a set of commitments and the ciphertext, it should tell the order of the attribute order that it wants to prove. Then, B can bind encrypted values to the received ciphertexts,

1. 2.

PSκA → PSκB :{Epk PSκB

→

A )|ı ∈ S ∗ }O (σı.j A A ,tA κ A)·E B −1 R PSA :{Epk ,tA (σı.j pkA ,tA ((σı.j ) )} A

where R denotes the random permutation of the corresponding set. After receiving the encrypted credential set, B performs the selective-tag encryption on B )−1 : =g−1/(xı +mBı.j ) by using the public key of PSκ (σı.j A and the tag according to the predefined order O. Then, B multiplies its own encryption together with the received encrypted set with order of O. Randomly permuting the generated encrypted set provides the randomness in determining two identical attributes among the whole intersection set. Finally, A uses the private key (χ, ψ) to decrypt the ciphertext in the set one by one. What A needs to do is to collect the number of “1” in the set, which implies the similarity score between A and B on specified sets SA∗ and SB∗ . Otherwise, decryption results are arbitrary bit strings A and σ B . due to the inequality of σı.j ı.j

5

P ERFORMANCE A NALYSIS

This section investigates how the security requirements are achieved in our proposed system for mHealth networks based on the objective and adversary model defined before, and how to enhance the resilience of the designed protocols to the general attacks and specific attacks on different privacy levels. The efficiency of the proposed system in terms of computation load and communication cost are also carefully evaluated based on both theoretical and experiment results.

5.1 Security Analysis 5.1.1 Identity and Attribute Privacy Since we offer the flexibility to patients and physicians to manage frequently changed pseudonyms to communicate with each other, the real identity is hidden from being traced. For the attribute privacy, the verification and comparison processes only use commitments of corresponding attributes and values. Without directly exposing plaintexts of such attributes, we ensure that adversaries cannot obtain detailed private information. Although in PL-2, patients obtain the identical attributes values from each other based on user’s intentions, it still preserves the privacy for the distinct attribute values from being leaked. One of the most important privacy requirements is the unlinkability between identities and attribute value set. Since our scheme applies randomness on both commitments of attribute values and pseudonyms, adversaries are not able to find the linkage between identities and attributes. Taking a step further, we ensure that commitments generated from the same attributes are distinct, which fundamentally prevents adversaries from obtaining attribute values of particular users. 5.1.2 Countermeasures to Possible Attacks We first give the security analysis on general attacks that all of the privacy levels will face. Then, we will discuss possible privacy leakages and attacks launched in each of the four levels. Tracing Attacks: Tracing attacks take place when adversaries collect enough privacy information to link a particular real identity. Our scheme perfectly thwarts this kind of attack by using random numbers in commitments and proofs. First of all, the adversary needs to be a valid user in the system, otherwise, its proofs cannot be verified by the other side. Second, even if the authentication process passes, a user will not keep using the same random numbers to generate commitments. According to the previous analysis, the adversary cannot trace any user because they are unable to establish the linkage between identities and attribute set. Collusion Attacks: Collusion attack is a very powerful attack and will severely threaten the security and privacy requirements of our scheme if not thwarted. According to our assumptions, collusion attacks can happen among users or between users and RC. The first type of collusion attack can be easily prevented. If a group of malicious users want to find out the privacy (like attributes) of a particular user, they have to launch a number of queries to this user. However, the user generates different commitments which may represent the same attributes by using different pseudonyms, attackers cannot tell the relationship between commitments and pseudo-identities. Taking a step further, the assumption of the NIWI system requires the composable witness indistinguishability, the adversary even cannot distinguish a real crs from a simulated crs. On a simulated crs, it is perfectly indistinguishable which witness the prover has used, in the sense that a verifier has no knowledge of the credential the prover has used. On the other hand, even if a malicious user colludes with the semi-trusted RC, our scheme provides solution.


We assume the purpose of malicious users is to find out a target user’s attribute value. If the authentication process passes, the adversary will hold the commitment of σı.j of the target user. Although the adversary is able to obtain all attributes of any user in the system from RC, it cannot find the linkage between the plaintext in RC and Com(σı.j ): = (f r1 +r3 ru , hr2 +r3 sv , σı.j gr1 +r2 +r3 (ru +sv ) ) due to the fact that only the target user knows random numbers ri contained in the corresponding commitments. Even adversaries launch the statistical attack together with RC, they cannot obtain credentials nor certificate since it is impossible for RC to tell the relationships among multiple commitments. Attacks on PL-0: Since PL-0 only considers the validity of attributes, the most possible attack is impersonation attack by using others’ credentials. However, because end users use pseudonyms, the only possible way is to call for TA to perform as an arbiter who can open the commitment and to trace back users who leak their credentials. Suppose we have a suspected user with a commitment Com(b), TA can use the system parameter (α, β) to open the commitment as follows: (f r1 +r3 ru )−1/α · (hr2 +r3 sv )−1/β · b · gr1 +r2 +r3 (ru +sv ) = b. Together with the pseudonym that this user used, we can locate the real identity of the adversary. Another possible attack that may compromise the attribute privacy of a user is what we call the “unique identification” attack. For example, if an attribute of a physician is the only one who has been verified by a particular professional authority (˜xı is unique), directly revealing ı for public verification discloses the identity in case of someone knows there is only one physician (with that particular attribute) who works at that hospital. To avoid this kind of attack, our system requires all users (physicians and patients) should have a same cardinality of their attribute set, which denotes the value of the public parameter remains stable for all physicians and patients. Thus, adversaries cannot identify a particular user according to different . Attacks on PL-1: Due to the asymmetric structure of PL-1, there are two types of attacks that could happen, which are “self-proving” and certificate leakage. For selfproving, a user may use the credential issued by RC and its own attribute mı.j to prove the equation (3) and (4). To eliminate this kind of attacks, we ask RC to give an addiε : = g(mı.j +ε) . tional certificate to the server side, which is δı.j Since the adversary is not aware of ε, it cannot generate the equation (4) by itself except using the additional certificate from the server. As another aspect of “self-proving” attack, malicious users may collude together to obtain the random number ε, which enables them to generate their own additional certificate in order to avoid the verification process. However, due to our assumption that the DLP is hard, adversaries cannot figure out the value of mı.j + ε based ε . Also, once the misbehavior is detected, we can use on δı.j the countermeasures in PL-0 to trace back and revoke the access privilege of the malicious users when they request the additional certificate from the server S. We further render RC and designated server S the ability to periodically update the random number ε, which hinders the revoked user to further utilize the previous additional certificate for the authentication. We note that we cannot prevent collusion attacks with RC in PL-1, because RC will directly tell

1937

attribute values together with the additional certificate once adversaries have already obtained it. However, in several kinds of scenarios, such as checking Boolean type attributes, we may not care about leaking the privacy of a server (i.e., a doctor’s affiliation). It is still reasonable to implement such scheme with the purpose of providing privacy for users, not the server. Certificate leakage is impossible also according to the assumption that the DLP problem is hard. Attacks on PL-2: In PL-2, each user mutually sends back random numbers used in generating commitments for equality check. We consider two major types of attacks that may potentially expose attribute values from both sides. The first type of attack comes from sending random numbers used for verification. For example, user B sends back to A the random number set {ti } for A to generate π˙ i . It is obvious that A can use the received t t t random number set to construct (1, 1, v˜ ı )u11 u22 u33 : = t1 +t2 +t3 (ru +sv ) ). Comparing to the (f t1 +t3 ru , ht2 +t3 sv , v˜ A ı · g B received dı.j : = (f t1 +t3 ru , ht2 +t3 sv , v˜ Bı · gmı.j +t1 +t2 +t3 (ru +sv ) ), it B

is difficult to derive gmı.j from the above values due to the assumption that DLIN problem is hard, which guarantees the attribute privacy when two users sends random numbers back and forth. The other possible attack performs on the outcome of comparison results. According to the requirements of PL-2, users learns nothing if their attribute values are not identical. The verification results returns 1 B A if and only if e(g, g)(xı +mı.j )/(xı +mı.j ) = e(g, g). Otherwise, the result outputs an arbitrary string instead of explicitly B listing the values of mA ı.j and mı.j . It is also possible for users to return incorrect random numbers and/or proofs, which renders the inconsistent comparison results on two sides. However, our system provides the arbitration algorithm which allows TA to be the arbiter and prevents from taking the risk. Attacks on PL-3: The privacy level 3 requires patients to mutually obtain a number of identical attributes instead of the detail of the intersection set. We have explained that the statistical attacks are infeasible for adversaries since a responser uses different pseudonyms to communicate. We further prohibit a user from responding to different queries in one time slot, or the colluded users may obtain the target user’s attribute value set based on the statistical results. Another type of attack is on the inconsistency of the similarity score, where users do not honestly encrypt and multiply −1 on the received packet. There are two possible the valid σı.j countermeasures for the inconsistency of the comparison results. First, we can apply another set of NIWI proofs that −1 . Then, we can check the validity and verifiability of σı.j utilize the homomorphic encryption to guarantee the consistency of the similarity score. Second, another possible countermeasure comes from [14] which encrypts random numbers used in generating the ciphertext and sends to the other end user for checking the consistency of the result. Due to page limit, we refer [14] for the detail which is applicable to our scheme.

5.2 Simulation Based Analysis We first implement our proposed scheme on laptops to test the theoretical results that it can achieve. Since the simulation results is mainly based on the computational capability

1938


Fig. 2. Computational cost for the proposed protocols. (a) PL-0. (b) PL-1. (c) PL-2. (d) PL-3.

of laptops, we can obtain the optimal theoretical data of our scheme. The following simulation concentrates on analyzing the computational cost of generating commitments, proofs, and proof verification process for all privacy levels.

5.2.1 Simulation Setting We used the Pairing-Based Cryptography (PBC-0.5.12) Library to implement our simulation. We take Tate pairing as our basic pairing operation. The elliptic curve we use for the our scheme is type A. A curve of such a type has the form of y2 = x3 +x. The order of the curve is around 160 bits, as is Fp , the base field, which is considered as the same security level as 1024-bit RSA. For the simulation setting, we use a laptop with an Intel processor 2.8GHz and 1GB RAM under the platform Ubuntu 11.10. All the timing reported below are averaged over 100 randomized runs. 5.2.2 Simulation Results We first give our simulation results with respect to the computational cost and number of verified attributes. In particular to the simulation, we set 100 as the maximum number of a patient’s attributes. As we can see from Fig. 2, the computational cost grows nearly linearly with the increase of the number of verified attributes in all four privacy levels. Moreover, regarding the specific situation in PL-2 and PL-3, we also analyze the impact of the percentage of identical attributes during the verification process as shown in Fig. 3 and Fig. 4. Simulation Results of PL-0 For the simplest case in PL-0, committing two variables consists of 6 group elements and the verification process costs 3 group operations. As we can see from Fig. 2(a), the computational cost grows linearly with the number of attributes. Meanwhile, the verification cost is more than both commitment and proof generation process. To verify 100 attributes only incurs less than 7s. •

Simulation Results of PL-1 In PL-1, a user needs 9 group elements to commit 3 variables, while the server side will incur 18 pairing operations for the verification. We also have ID-based encryption and decryption process in PL-1, which incurs at most one pairing computation in each of the encryption, decryption, signature generating and verification processes, respectively, according to [27], [31]. So, the proofs in PL-1 consists of 35 group elements, in which a user needs to calculate 13 pairing operations. In Fig. 2(b), we combine the computation cost derived in PL-1 since we need to verify

two equations identified in Section 4.3.2. Compare to PL0, the computational cost for proof generation overwhelms the commitment generation process. All the computational costs increase linearly with the increment of verified credentials and certificates. Simulation Results of PL-2 For the authentication between two patients in PL-2, it will have 54 group operations. In addition, a patient needs 9 group elements for checking the equality of credentials on each side. Thus, PL-2 incurs approximately 72 group operations in total. Since patients mutually generate an additional proof for verifying the equality, it is obvious shown in Fig. 2(c) that the computational cost for generating NIWI proofs increases dramatically compared with commitment generation and verification processes. As an important factor, the percentage of identical attributes largely affects the verification time. In Fig. 3(a), the commitment and proof generation remain the same with the increment of identical attributes, but the verification cost grows when the number of identical attribute increases. Also, we give a more detailed simulation results on the computational cost on the percentage of identical attributes and the number of compared attributes in Fig. 4. According to the simulation results, the total computational cost for the verification is less than 12s even all of 100 compared attributes are identical. •

Simulation Results of PL-3 With the additional 15 group elements in NIZK and 5 on the ciphertext, PL-3 totally consists of 94 group elements. In Fig. 2(d), we combine the NIZK commitments and proof generation together to show patients’ cost for the comparison, and the computational cost of proofs and verification grow nearly linearly with the number of compared attributes. On the other hand, the verification cost is less •

•

Fig. 3. Impact of percentage of identical attributes. (a) PL-2. (b) PL-3.


1939

Fig. 4. Verification cost of PL-2.

than the cost of proofs and commitment generation, which implies the fact that we need to commit a great number of variables in Eq. (9). Also, as we can see, compared with the proof generation and verification costs, the reported time for homomorphic encryption and decryption process is negligible. Regarding the percentage of identical attribute in PL-3, it is shown in Fig. 3(b) that the computational costs of both the commitment generation and verification process are not affected by the increment of the percentage of identical attributes. To some extent, this fact reflects that no user can guess any clue regarding their same attributes using this reported time results.

5.3 Experiment Based Analysis We also conduct experiments on smart phones to test the performance of our proposed schemes. According to the report [33] from U.S. National Institute of Health (NIH), patients’ personal health records always consist of more than 10 crucial attributes, each of which may contain different numbers of values. Those attributes include blood type, previous medication, allergies reactions, past medical history, etc. We also note that different eHealth or mHealth systems may have different numbers of attributes and attribute values to represent past and current patient situation. For the implementation of our experiments, we use ten attributes to represent a particular patient. The experiment focuses on the computational and communication cost of our proposed scheme. 5.3.1 Experiment Settings We use Java Pairing Based Cryptography (jPBC-1.2.0) Library to implement our scheme. We also use type A curve as the elliptic curve. For the experiment, we use the smart phone Nexus S with a Samsung Exynos 3110 processor. The smart phone has 1 GHz ARM Cortex A8 core, and 512 MB RAM. The experiment is built on the platform Android 2.3.2. 5.3.2 Experimental Results and Performance Analysis Compared to the results in Fig. 2, the computational cost in terms of time consumption shown in Fig. 5 is greater than the theoretical results, due to the fact that the computation capability of the laptop, 2.8 GHz is much faster than the smart phone. Therefore, the proposed scheme takes more time to process. However, the pattern of the experimental data reflects the theoretical analysis in the following aspects. First, the verification cost overwhelms the proof

Fig. 5. Experimental results on computational cost. (a) PL-0. (b) PL-1. (c) PL-2. (d) PL-3.

and commitment generation cost in PL-0, PL-1 and PL-3. For the most time consuming scenario in PL-1, the verification of 10 attributes takes up to 70s, but since we deploy a high-performance server for the verification, it would not become a burden for patients. In PL-3, patients not only need to verify the authenticity of attributes and the corresponding values, but also generate the additional proofs for equality verification, where the process has 4 equations to get verified. As a result, the verification time becomes the major time consuming part in PL-3. For PL-2, after patients mutually verify the authenticity of their attributes and the corresponding values, they generate another proof based on received commitments. Since it only has one equation that needs to get verified, the total verification time is smaller than PL-3. On the other hand, we also observe that the NIWI proof generation cost more time in PL-2 than any other three levels. It is because patients need to mutually compute the proof for equality test, which becomes the main reason that impedes the computation time. For the communication cost during the protocols run, we use Bluetooth v2.1 as our transmission technology under IEEE standard 802.15.1. We use two Nexus S smart phones to test the end-to-end delay when we apply our scheme from PL-0 to PL-3. According to the standard, the average transmission rate for Bluetooth v2.1 is 1MB/s. As we can see from Fig. 6, the communication cost for the progressive privacy levels grow nearly linearly with the increment of the number of attributes. The average transmission rate under our experiments is approximately 720kbps. Based on the above results, we show that our protocols has low communication end-to-end delay compared with the computational costs. Since the Bluetooth packet has 72 bits access code and 54 bits header at the beginning of every packet, the endto-end delays of all four levels start to grow linearly when the payload, the commitments or proofs, is greater than the

1940


Fig. 6. Communication cost.

length of 126 bits. The access code includes 4 bits preamble, 4 bits tailer and 64 bits sync code which intends for synchronization. We apply Type A curve as our basic elliptic curve which has 80-bit security level. In PL-0, the total length for a verification packet includes 2 commitments and 3 proofs, which takes up to 400 bits for one attribute. From PL-1 to PL-3, the length of transmitted packets are 800 bits, 1040 bits and 2080 bits for verifying and authenticating a single attribute. We note that when the data length is greater than 2745 bits, we need to break the data into multiple packets. Therefore, the end-to-end delay increases faster when the number of attributes increases.

6

C ONCLUSION

In this paper, we propose a framework of privacypreserving attribute-based authentication system in mHealth networks. Our framework applies the noninteractive proof system as the basic building block, and we give formal definitions of four progressive privacy levels. The attribute-based authentication schemes designed for higher privacy levels preserve more stringent privacy on attributes and attribute values, but cost more computation and communication resources. Based on the security analysis, we show that our scheme meets both the verifiability and privacy of attributes and attribute values. According to extensive theoretical and experimental results, we show the efficiency and feasibility of our proposed scheme under different privacy requirements.

ACKNOWLEDGMENTS This work was partially supported by the U.S. National Science Foundation under grants CNS-1147813 and CNS0916391, and National Natural Science Foundation of China under Grants 61328208 and 61202140. The authors thank X. Liu for the support of several experiments and valuable discussion. The preliminary version of this paper was published on the 32nd International Conference on Distributed Computing Systems (ICDCS), Macau, Jun. 2012.

R EFERENCES [1] [Online]. Available: http://www.research2guidance.com/us-1.3-b illion-the-market-for-mhealth-applications-in-2012/ [2] Employee Benefit Research Institute. (2008). Retirement Confidence Survey [Online]. Available: http://www.ebri.org/surveys/hcs/ [3] L. Sweeney, “K-Anonymity: A model for protecting privacy,” Int. J. Uncertain. Fuzz., vol. 10, no. 5, pp. 557–570, 2002.

[4] [Online]. Available: http://www.healthegift.com/page/50 [5] [Online]. Available: http://www.nytimes.com/2011/11/05/us/u cla-health-system-warns-about-stolen-records.html [6] Ponemon Institute. (2012). Third Annual Survey on Medical Identity Theft [Online]. Available: http://www.ponemon.org/ [7] [Online]. Available: http://healthcaremgt.net/blog/2011/08/areyou-educating-patients-on-ehr/ [8] D. Zismer, J. McCullough, and P. Person, “Integrated health care economics. Part 2: Understanding the revenue drivers in fully integrated community health systems,” Physician Exec., vol. 35, no. 4, pp. 26–28, 2011. [9] A. Moumtzoglou and A. Kastania, E-Health Systems Quality and Reliability: Models and Standards. Hershey, PA, USA: IGI Global, 2010. [10] M. Li, S. Yu, K. Ren, and W. Lou, “Securing personal health records in cloud computing: Patient-centric and fine-grained data access control in multi-owner settings,” in Proc. SECURECOMM, Singapore, 2010, pp. 89–106. [11] J. Benaloh, M. Chase, E. Horvitz, and K. Lauter, “Patient controlled encryption: Ensuring privacy of electronic medical records,” in Proc. ACM Workshop CCSW, New York, NY, USA, 2009, pp. 103–114. [12] J. Jin, G.-J. Ahn, H. Hu, M. J. Covington, and X. Zhang, “Patientcentric authorization framework for sharing electronic health records,” in Proc. 14th SACMAT, New York, NY, USA, 2009, pp. 125–134. [13] M. Li, N. Cao, S. Yu, and W. Lou, “FindU: Privacy-preserving personal profile matching in mobile social networks,” in Proc. 30th IEEE INFOCOM, Shanghai, China, Apr. 2011, pp. 2435–2443. [14] W. Dong, V. Dave, L. Qiu, and Y. Zhang, “Secure friend discovery in mobile social networks,” in Proc. 30th IEEE INFOCOM, Shanghai, China, Apr. 2011, pp. 1647–1655. [15] R. Agrawal, A. Evfimievski, and R. Srikant, “Information sharing across private databases,” in Proc. ACM SIGMOD, New York, NY, USA, 2003, pp. 86–97. [16] R. Fagin, M. Naor, and P. Winkler, “Comparing information without leaking it,” Commun. ACM, vol. 39, no. 5, pp. 77–85, May 1996. [17] L. Kissner and D. Song, “Private and threshold set-intersection,” in Proc. CRYPTO, Aug. 2005. [18] N. Eagle and A. Pentland, “Social serendipity: Mobilizing social software,” IEEE Pervasive Comput., vol. 4, no. 2, pp. 28–34, Apr. 2005. [19] M. Blum, P. Feldman, and S. Micali, “Non-interactive zeroknowledge and its applications,” in Proc. 20th STOC, New York, NY, USA, 1988, pp. 103–112. [20] J. Groth and A. Sahai, “Efficient non-interactive proof systems for bilinear groups,” in Proc. 27th EUROCRYPT, Istanbul, Turkey, 2008, pp. 415–432. [21] J. Bethencourt, E. Shi, and D. Song, “Signatures of reputation: Towards trust without identity,” in Proc. 14th Int. Conf. FC, Jan. 2010. [22] J. Groth, “Fully anonymous group signatures without random oracles,” in Proc. 13th ASIACRYPT, Kuching, Malaysia, pp. 164–180, 2007. [23] M. Belenkiy, M. Chase, M. Kohlweiss, and A. Lysyanskaya, “Noninteractive anonymous credentials,” Cryptology ePrint Archive, Report 2007/384, 2007 [Online]. Available: http://eprint.iacr.org/ [24] J. Bethencourt, A. Sahai, and B. Waters, “Ciphertext-policy attribute-based encryption,” in Proc. IEEE Symp. Security Privacy, Berkeley, CA, USA, 2007, pp. 321–334. [25] M. Barua, X. Liang, R. Lu, and X. Shen, “Peace: An efficient and secure patient-centric access control scheme for ehealth care system,” in Proc. IEEE INFOCOM, Shanghai, China, Apr. 2011, pp. 970–975. [26] S. Narayan, M. Gagné, and R. Safavi-Naini, “Privacy preserving EHR system using attribute-based infrastructure,” in Proc. ACM CCSW, New York, NY, USA, 2010, pp. 47–52. [27] D. Boneh and M. Franklin, “Identity-based encryption from the Weil pairing,” in Proc. Adv. CRYPTO, Santa Barbara, CA, USA, 2001, pp. 213–229. [28] C. Shirky, Here Comes Everybody: The Power of Organizing Without Organizations, 1st ed. New York, NY, USA: Penguin Press HC, 2008. [29] D. Boneh, X. Boyen, and H. Shacham, “Short group signatures,” in Proc. 24th CRYPTO, Santa Barbara, CA, USA, 2004, pp. 41–55. [30] D. Boneh and X. Boyen, “Short signatures without random oracles and the SDH assumption in bilinear groups,” J. Cryptology, vol. 21, no. 2, pp. 149–177, 2008.


[31] F. Hess, “Efficient identity based signature schemes based on pairings,” in Proc. 9th SAC, Newfoundland, Canada, 2003, pp. 310–324. [32] P. MacKenzie, M. K. Reiter, and K. Yang, “Alternatives to non-malleability: Definitions, constructions, and applications (extended abstract),” in Proc. TCC, Cambridge, MA, USA, 2004, pp. 171–190. [33] (2009). Electronic health records place 1st at Indy 500. NIH MedlinePlus Mag. [Online]. 4(3), pp. 16–17. Available: http://www.nlm.nih.gov/medlineplus/magazine/issues/pdf/ med_mag_summer2009.pdf

Linke Guo received his B.E. degree in electronic information science and technology from Beijing University of Posts and Telecommunications in 2008. He received M.S. and Ph.D. degrees in Electrical and Computer Engineering from the University of Florida in 2011 and 2014, respectively. He will join the Department of Electrical and Computer Engineering, Binghamton University, State University of New York as an assistant professor in August 2014. His research interests include network security and privacy, social networks, and applied cryptography. He is currently a student member of the IEEE and ACM. Chi Zhang received the B.E. and M.E. degrees in Electrical and Information Engineering from Huazhong University of Science and Technology, China, in 1999 and 2002, respectively, and the Ph.D. degree in Electrical and Computer Engineering from the University of Florida in 2011. He joined the University of Science and Technology of China in September 2011 as an Associate Professor of the School of Information Science and Technology. His research interests are in the areas of network protocol design and performance analysis, and network security particularly for wireless networks and social networks. He has published over 60 papers in journals such as IEEE/ACM Transactions on Networking, IEEE Journal on Selected Areas in Communications, and IEEE Transactions on Mobile Computing and in networking conferences such as IEEE INFOCOM, ICNP, and ICDCS. He has served as the Technical Program Committee (TPC) members for several conferences including IEEE INFOCOM, ICC, GLOBECOM, WCNC and PIMRC. He is the recipient of the 7th IEEE ComSoc Asia-Pacific Outstanding Young Researcher Award. He is a member of the IEEE.

1941

Jinyuan Sun received the BSc degree in computer information systems from Beijing Information Technology Institute, China, in 2003, the MASc degree in computer networks from Ryerson University, Canada, in 2005, and the PhD degree in electrical and computer engineering from the University of Florida, in 2010. She was a Network Test Developer at RuggedCom Inc., Ontario, Canada, 2005-2006. She has been an assistant professor in the Department of Electrical Engineering and Computer Science at University of Tennessee Knoxville since August 2010. Her research interests include the security protocol and architecture design of wireless networks. She is a member of the IEEE and ACM. Yuguang Fang (F’08) received a BS/MS degree from Qufu Normal University, Shandong, China in 1987, a Ph.D degree from Case Western Reserve University in 1994, and a Ph.D. degree from Boston University in 1997. He joined the Department of Electrical and Computer Engineering at the University of Florida in 2000 and has been a full professor since 2005. He held a University of Florida Research Foundation (UFRF) Professorship from 2006 to 2009, a Changjiang Scholar Chair Professorship with Xidian University, China, from 2008 to 2011, and a Guest Chair Professorship with Tsinghua University, China, from 2009 to 2012. Dr. Fang received the US National Science Foundation Career Award in 2001 and the Office of Naval Research Young Investigator Award in 2002, and is the recipient of IEEE ICNP (2006). He has also received a 2010-2011 UF Doctoral Dissertation Advisor/Mentoring Award, 2011 Florida Blue Key/UF Homecoming Distinguished Faculty Award, and the 2009 UF College of Engineering Faculty Mentoring Award. He is the Editor-in-Chief of the IEEE Transactions on Vehicular Technology, was the Editor-in-Chief of IEEE Wireless Communications (2009–2012) and serves/served on several editorial boards of journals including IEEE Transactions on Mobile Computing (2003–2008, 2011-present), IEEE Transactions on Communications (2000–2011), and IEEE Transactions on Wireless Communications (2002–2009). He has been actively participating in conference organizations such as serving as the Technical Program Co-Chair for IEEE INOFOCOM’2014 and the Technical Program Vice-Chair for IEEE INFOCOM’2005. He is a fellow of the IEEE. For more information on this or any other computing topic, please visit our Digital Library at www.computer.org/publications/dlib.