2922 IEEE INTERNET OF THINGS JOURNAL, VOL. 6, NO. 2, APRIL 2019

Security Analysis of Mobile Device-to-DeviceNetwork Applications

Kecheng Liu, Student Member, IEEE, Wenlong Shen, Member, IEEE, Yu Cheng , Senior Member, IEEE,

Lin X. Cai, Member, IEEE, Qing Li, Member, IEEE, Sheng Zhou , Member, IEEE,

and Zhisheng Niu , Fellow, IEEE

Abstract—Mobile device-to-device (D2D) network has nowbecome a standardized feature in many mobile devices, by whichmobile devices can communicate with each other even when com-mercial Internet access is not available. Because D2D network isexpected to be an intrinsic part of the Internet of Things (IoT)and mobile device is the smartest and the most advanced com-mercial device in everyday usage, the D2D feature and relatedsecurity protocols it adopts influences the design and implemen-tation of many other IoT devices. While D2D network providestangible benefits to users, it also raises the security risks ofinformation leaking. This paper presents an in-depth empiri-cal security analysis on mobile D2D network among Androiddevices. Android apps could establish a mobile D2D networkin various ways, including Wi-Fi hotspot, Wi-Fi Direct, andBluetooth. Those mobile D2D protocols normally take differentprotection mechanisms, which makes security investigation con-siderably challenging. In this paper, we focus on most popularapps in the Google Play Store, with aggregated downloads morethan 500 million. Our analysis reveals some critical vulnerabili-ties. The key findings are bi-fold. First, the current mobile D2Dnetwork framework enabled by Android has significant flaw ofoverprivilege issue. Second, we have identified that most datatransfer over mobile D2D network is unencrypted. Furthermore,we exploit the identified Android framework flaws to constructthree proof-of-concept attacks and we conclude this paper withsecurity lessons and suggestions of possible solutions against theidentified security issues.

Index Terms—Android, device-to-device (D2D), informationsecurity, Internet of Things (IoT), overprivilege.

I. INTRODUCTION

MOBILE device-to-device (D2D) network provides aparadigm to facilitate data exchange among physically

Manuscript received March 23, 2018; revised June 24, 2018 andSeptember 26, 2018; accepted October 11, 2018. Date of publicationOctober 22, 2018; date of current version May 8, 2019. This work wassupported in part by the NSF under Grant ECCS-1610874, Grant ECCS-1554576, and Grant CNS-1816908, in part by the National Natural ScienceFoundation of China under Grant 61628107, Grant 61861136003, Grant61571265, Grant 91638204, and Grant 61621091, and in part by the UnitedTechnologies Research Center under Grant A18-0056-001. (Correspondingauthor: Yu Cheng.)

K. Liu, W. Shen, Y. Cheng, and L. X. Cai are with the Departmentof Electrical and Computer Engineering, Illinois Institute of Technology,Chicago, IL 60616 USA (e-mail: kliu6@hawk.iit.edu; wshen7@hawk.iit.edu;cheng@iit.edu; lincai@iit.edu).

Q. Li is with the Network Protection Products BusinessUnit, Symantec Cooperation, Mountain View, CA 94043 USA(e-mail: qing_li@symantec.com).

S. Zhou and Z. Niu are with the Tsinghua National Laboratory forInformation Science and Technology, Tsinghua University, Beijing 100084,China (e-mail: sheng.zhou@tsinghua.edu.cn; niuzhs@tsinghua.edu.cn).

Digital Object Identifier 10.1109/JIOT.2018.2877174

proximate devices. As an alternative network structure toinfrastructure-based network, a mobile D2D network can beestablished without the presence of base stations or accesspoint. Data transfer takes place directly among connecteddevices without any interaction with other devices outside thenetwork [2], [8].

Relying on the infrastructure-based network is not alwaysthe optimum route to transmit and receive data, especiallyconsidering the rapid development of Internet of Things(IoT). In an IoT ecosystem, devices initiate communicationsamong themselves. Due to constrained battery life, process-ing power, memory, and uncertainty in wireless environment,building an IoT system that solely relies on cloud networkis extremely challenging and impractical. The fundamentalrequirement of the IoT is to provide connectivity betweendevices. Thus, achieving a seamless end-to-end D2D commu-nication is imperative for the success of the IoT. The rapidgrowth of mobile devices has made an inception of its leadingrole in terms of Things (devices). They have been optimizedin all aspects, including power, usability, and networking, andhave become a significant part of the IoT ecosystem. Forboth the compatibility and security reasons, many IoT deviceshave adapted the D2D network feature from mobile devicesand have followed their design mechanisms [4]. Mobile D2Dnetwork may enable applications over free spectrum, e.g.,WiFi band, without involving commercial Internet access [18].D2D network can also be utilized to offload cellular data traf-fic for new applications, such as data sharing, multiplayergaming, and video streaming [9], [24]. In this paper, weparticularly focus on mobile D2D network enabled by Wi-Fi-based technologies. Such D2D network is infrastructureless,self-formed networks, and allow free usage without paymentcharge. In fact, the post popular mobile D2D network appscurrently available on market are over such WiFi-based D2Dnetwork.

Our group performed, to our best knowledge, the firstsecurity analysis of the mobile D2D network framework onAndroid. Specifically, we empirically evaluated the securitydesign of the most popular smart phone platform for mobileD2D network on Android. We focused on the frameworkof the network driver and the software implementation ofapps because they are the substrates that unify application,protocols, and devices to realize mobile D2D network benefits.

Our Contributions: We discovered security-critical designflaws in the following areas.

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

LIU et al.: SECURITY ANALYSIS OF MOBILE D2D NETWORK APPLICATIONS 2923

1) Android D2D network needs implicit configurations tomake sure the network is safe. The open-sourced APIdoes not present such configuration.

2) Android D2D network framework has significant over-privilege issues. Granted permission to access Wi-Fistates, any apps installed on the smart phone couldaccess the Wi-Fi hotspot feature and the Wi-Fi Directfeature on the device, even if those features are notrequired by that app. As a result, key information,including password, about the D2D network is exposed,leaving the network unprotected.

3) Once received the key information about the D2Dnetwork, any device could hack into the network silentlysince the network authentication mechanism is evitable.An attacker could join the D2D network without anyauthentication process. The peers in the network maynot even notice.

4) Coarse security implementation of D2D apps leaves dataunencrypted. Attackers could eavesdrop on the networkand steal information.

We exploited an aggregation of framework design flaws toshow various security problems conspired to weaken mobileD2D network security. We constructed three proof-of-conceptattacks.

1) We exploited an exiting mobile D2D app available on theapp store to snoop network information. Nearby devicesrunning the same hacking program could silently jointhe network.

2) We eavesdropped on the D2D network and once a filetransfer service is initiated, the hacking program cansteal the file.

3) We captured and investigated the unencrypted D2Dnetwork packets on another existing mobile D2D app,which disclose the key information during a file transfer.

Finally, in our forward looking analysis, we distilled the keystudies to establishing secure mobile D2D network framework.We couple the lessons with a breakdown of pros and consof the tradeoffs in constructing such framework. Our analysissuggests that most problems are readily solvable.

The remainder of this paper is organized as follows.Section II introduces the mobile D2D network architectureand the threat model. Section III presents our analysis onthe potential attacks that the D2D network is facing. InSection IV we analyze four most popular D2D applicationsand show that they suffer from the framework design flaws.We presents three proof-of-concept attacks with experimentalresults in Section V, followed by the improvement sugges-tions in Section VI. Section VII reviews the related work andSection VIII concludes this paper.

II. MOBILE D2D NETWORK ARCHITECTURE

AND THREAT MODEL

A. Wi-Fi Hotspot

Wi-Fi hotspot, also known as Wi-Fi Tethering, has beengaining popularity as a convenient, on-the-move, and cost-effective wireless Internet access technology. A Wi-Fi hotspotnetwork is a star-like cluster-based network with a central node

Fig. 1. IOS recognizes the hotspot network created by an Android apputilizing WPA_PSK protection mechanism and alerts the user the securitytype is not considered secure.

providing 3G/4G data tethering and allowing plural surround-ing nodes to join and to gain Internet access. In this paper wewill henceforth refer to the central node and the surroundingnode as the cluster head (CH) and the cluster member (CM).

In Android system, developers can access Wi-Fi hotspot fea-ture programmatically. This is how they use it to implementthe D2D feature in apps. However, due to Android D2D frame-work restrictions, programming D2D implementation throughAPI may cause issues from three aspects.

1) Wi-Fi Tethering is System API: To turn on/off the Wi-Fihotspot feature programmatically, the developer must have anopen-sourced API to control the hotspot driver. However, theWi-Fi hotspot enabling method is a system API. In order toaccess this API, the developer must use reflection in Java toinvoke this method using the method’s name. However, usingreflection is problematic because it undermines the runtimecertainty. More specifically, the Java compiler cannot check onreflection. The reflected code may compile but may explodeat runtime because reflection uses the name for the methodrather than referring to the actual method. The method toenable/disable Wi-Fi hotspot can be invoked through reflectionbut it subverts the strength of Java.

2) WPA2_PSK is System API: To create a WPA2_PSKsecured hotspot network programmatically, the developer mustset the Wi-Fi configuration parameter to support WPA2_PSKkey management. However, the WPA2_PSK is a system APIas well; developers cannot access this security setting directly.Even though Java reflection also works on WPA2_PSK, manydevelopers neglect the importance of network security andleave the network vulnerable. We found out several highdownload apps insecure due to coarse-grained software imple-mentation. They use WPA_PSK as an alternative securitysetting to protect the hotspot network. Many commercialdevices today recognize WPA_PSK as an insecure protection.Fig. 1 shows the Wi-Fi interface of an IOS device connect-ing to a hotspot network created by an Android app. TheIOS device recognizes that the network utilizes WPA_PSKto encrypt data and it alerts the user the network is insecure.

3) Hotspot Without Password Absolutely Unprotected: Theuse of hotspot imposes the risk of people capturing real-time traffic over the wireless connections. Attackers can easilycapture, from the air, the packets of unsecured connectionsto hotspots. It is intuitive that open hotspot has no securityprotection but many hundred million download apps still

2924 IEEE INTERNET OF THINGS JOURNAL, VOL. 6, NO. 2, APRIL 2019

TABLE ICOMPARISON BETWEEN WI-FI DIRECT AND WI-FI HOTSPOT

ON ANDROID PLATFORM

choose to use open hotspot, seeking to maximize the conve-nience. Those apps leverage the user experience over securitybut expose the information of the smart phone to the public.

B. Wi-Fi Direct

The essential functionality of Wi-Fi Direct is to enableWi-Fi devices to connect directly without joining a centralAP. Wi-Fi Direct is integrated into Android as Wi-Fi Directand the API is standardized by Android since Android 14.Wi-Fi Direct is a software realization sharing the same networkinterface card with the Wi-Fi module. Comparing with hotspot,there are many similarities and differences. We summarizethem in Table I.Wi-Fi

1) Wi-Fi Direct Versus Wi-Fi Hotspot: Direct inherits thehigh-speed advantages from 802.11. The data transfer rate canreach 54 Mb/s. Since both Wi-Fi Direct and hotspot uses thesame hardware, the RF coverage is 100 line-of-sight.

Similar to a hotspot, the Wi-Fi Direct network is also a star-like, cluster-based network with a central node acting as a CHand surrounding nodes as CMs. In contrast with hotspot, theWi-Fi Direct cluster is defined as a group in the Wi-Fi Alliancestandard. The CH is defined as the group owner (GO) and theCM is defined as the group member (GM).

Like a Wi-Fi AP, a GO is visible by other Wi-Fi devices onthe Wi-Fi scan list; therefore, GO is sometimes called a softAP. Nevertheless, since Wi-Fi Direct is designed to provide theD2D feature so the GO does not provide the Internet tetheringfunction to the GM.

2) Two Connection Types: There are two ways to join aWi-Fi Direct group: 1) through Wi-Fi Direct connection and2) through legacy connection. A wireless link connecting adevice to a GO following the Wi-Fi Direct protocol is called aD2D connection. On the other hand, any Wi-Fi device, regard-less of Wi-Fi Direct support, can associate to the GO followingthe Wi-Fi protocol. The associated client device is defined asa legacy client and the corresponding connection is called alegacy connection.

3) Different Security Mechanisms: Wi-Fi Direct alsoacquires all the security mechanism from 802.11. A Wi-FiDirect network is by default protected by WPA2_PSK. Asdiscussed previously, a GO is a soft AP which can be con-nected through a legacy connection. Once created, the soft

AP is WPA2_PSK encrypted and the password is randomlygenerated by the network driver.

Additionally, if the group is established through the Wi-FiDirect protocol, extra protection mechanisms are introducedin the standard. A human-involved paring authentication pro-cess, which is a software transform of Wi-Fi protectionsettings (WPS), is integrated into the Android network driver.Specifically, there are three WPS options: 1) display pin con-figuration; 2) keypad pin configuration; and 3) push buttonconfiguration. Since the two-way authentication is a require-ment by the Wi-Fi Direct standard, it is an inevitable procedureduring a D2D connection using Android devices.

4) Service Broadcast and Discovery: One of the mostimportant features of Wi-Fi Direct is connectionless servicebroadcast and discovery (SBD). Using SBD allows devicesto discover the services of nearby devices directly, withoutbeing connected to a network. A device can also advertisethe services running on it. These capabilities help devicescommunicate between apps, even when no local network isavailable.

C. Threat Model

Our effort concentrated on systematically discovering andexploiting mobile D2D network framework design vulnerabil-ities. Any scheme relevant to the above aspects were withinscope. We did not study attacks that attempt to crack thesecurity algorithm of the D2D network with advanced hack-ing tools. Bugs in those areas were discussed and fixed in802.11 security analysis. In contrast, attacks focused on soft-ware design flaws had extensive influences since programmingframeworks were burdensome to change without significantdisruption once there was a large set of applications that usedthe framework.

We focused this paper on D2D communication and relatedapplications which are designed independent of Internet avail-ability. We aimed to create an offline attacking scenarioregardless whether Android devices, not limited to smart-phones, have Internet access or not. The key point we aretrying to demonstrate is despite Android implements the D2Dfeatures following the well-defined network standards andit includes the well-known security mechanism, the D2Dnetwork it creates has a backdoor to the intruders.

D. Conclusions of the Section

In this section, we introduce the background and the archi-tectural design of two mobile D2D network protocols basedon the 802.11 standard: Wi-Fi hotspot and Wi-Fi Direct. Bymaking comparison and contrast, we claim that Wi-Fi Directis better implemented and protected on Android platform.The most severe issue of Wi-Fi hotspot is the absence ofopen-sourced API and the inadequacy of appropriate securityconfigurations. Android does not present an implicit settingfor developers to securely invoke the Wi-Fi hotspot feature.Nevertheless, many apps still prefer to using it as the D2Dnetwork basis due to its convenience rather than Wi-Fi Direct.

In later sections, we will illustrate our security analy-sis of the mobile D2D network framework. Many of our

LIU et al.: SECURITY ANALYSIS OF MOBILE D2D NETWORK APPLICATIONS 2925

Fig. 2. Over privilege issue in Android network framework caused bypermission management.

investigations depend on the details emphasized on thissection.

III. SECURITY ANALYSIS OF MOBILE D2DNETWORK FRAMEWORK

We break down the security of the Mobile D2D networkframework into four general themes. Our methodologyinvolves creating a list of attack models based on this paper ofthe mobile D2D network architecture and extensively testingeach potential attack model with prototype mobile D2D apps.We describe each investigation and will expound our findingslater in this section.

A. Overprivileged D2D Network Access

Android uses permission to avoid overprivilege issues. Tomaintain security for the system and users, Android requiresapps to request permission before the apps can use certainsystem data and features. Depending on how sensitive the areais, the system may grant the permission automatically, or itmay ask the user to approve the request. Thus, if an applicationdoes not request to use a certain feature but the permission toaccess the feature is still granted, this accidental permissionacquisition is an example of overprivilege.

As shown in Fig. 2, Android does not provide any per-mission to particularize the accesses to Wi-Fi hotspot andWi-Fi Direct; which means to establish an 802.11-based D2Dnetwork, an application only has to acquire the Wi-Fi per-missions. This framework design articulates the overprivilegeproblems because any app that has access to the Wi-Fi fea-ture will have the privilege to utilize the D2D network featureas well.

The permissions to use Wi-Fi is not a sensitive permis-sion for users because most applications installed on the smartphone need to have the access to use Wi-Fi and the Internet,such as the music app, the GPS app and the social networkapp. Users will not pay extra attention to an app that requests

the usage of Wi-Fi if they believe that application needs touse the Internet.

This framework design leaves applications that rely on theD2D feature in significant danger because there is only onenetwork driver on the Android device and the informationabout the network is singleton; which means the SSID andthe password are consistent on the framework level regardlesswhich app is trying to get it. The overprivilege issue allowsalmost every app on the device to more or less access the keyinformation to the D2D network. It gives attackers the opportu-nity to maliciously manipulate the network, including interceptdata transmission, eavesdropping, sending false signals etc.

In order to take advantage of the framework design flaw, allattackers need to do is to install a benign-but-malicious appthat requests the permission to access Wi-Fi. The frameworkwould ask the user to authorize the permission. Unfortunately,the request is too common so that it will neither alert the usernor the system; therefore, the user is very unlikely to deny therequest, making the attack an essentially effortless assignment.

Once the benign-but-malicious app is installed on the smartphone, the sensitive network information is at risk and anoffline leakage attack can be executed by the third party. Wewill discuss this attack model in the following paragraphs.

B. Sensitive Network Information Leakage

As discussed in Section IV-A, the overprivilege issue due tocoarse-grained framework opens a back door to a third partyapp to access key information about the network. Because theframework does not place any restrictions on outbound Internetcommunication either, such a design flaw allows maliciousapps to abuse this ability to leak sensitive information from avictim’s smart phone.

However, information leakage via the Internet is not whatwe concentrate on for two reasons. First, in a D2D networkscenario, Internet is assumed unavailable; second, D2D datais transmitted locally without the Internet access. We exploitan offline attack model based on the D2D network architec-ture described in Section III. Following our attack logic, athird party device can receive key information about the D2Dnetwork in offline mode.

Fig. 3 depicts the attack model. Users Alice and Bob bothhave a D2D app installed on their smart phones and theyuse the app to establish a D2D network. Because the wire-less range is 100 m line-of-sight, Alice and Bob must be inphysical proximity to maintain the wireless connection. OnAlice and Bob’s smart phones, a benign-but-malicious appis also preinstalled which has acquired the Wi-Fi permissionfrom the users. Due to the overprivilege issue discussed inSection IV-A, this app can obtain the key information aboutthe D2D network.

We assume Trudy is the attacker and in order to perform anoffline attack, he must locate in physical proximity to Aliceand Bob as well. His smartphone must be able to detect thesignals transmitted by Alice and Bob’s smart phones. This isnot an impossible scenario because Trudy can pretend to be arandom person standing near Alice and Bob but far enough sothat they believe nobody can see their operations on their smart

2926 IEEE INTERNET OF THINGS JOURNAL, VOL. 6, NO. 2, APRIL 2019

Fig. 3. Offline attack model to obtain key information about the network.

Fig. 4. Flowchart to cause network information leakage due to frameworkdesign flaws.

phones. Furthermore, Alice, Bob, and Trudy’s smart phonesare completely offline in our attack model.

The operational flow chart of the malicious app installed onAlice and Bob’s smart phones is shown in Fig. 4. The purposeof the malicious app is to induce network information leakageso the first thing it needs to examine is the D2D networkstatus. If the smart phone is not part of the D2D network,the malicious program maintains its benign behavior. As soonas it detects the network establishment, it will change to thehacking mode. The network establishment event is triggeredby multiple Android system intents. We contain all events,including Wi-Fi Direct group creation, D2D connection, Wi-Fihotspot creation, and Wi-Fi network association, in the sameintent receiver.

After the app receives the network establishment event, itidentifies which type of the D2D network the smart phonehas joined. If the network is a hotspot network, it examineswhether the device is a CH or a CM. Similarly, if the networkis a Wi-Fi Direct network, it examines whether it is a GO ora GM. We separate the procedures because only CH and GOcontain the key information about the network. The D2D appli-cation determines either Alice or Bob become the access pointof the network, but to Trudy, it does not make any differencewhich smart phone is the access point. All Trudy anticipatesis the network name and its key.

We will first discuss the situation if the smart phone isa GO. Because of the overprivileged framework design, themalicious app now can retrieve the SSID and the password ofthe Wi-Fi Direct network. Android provides the open-sourcedAPI to achieve this. After the key information has been stolen,

the malicious app will take advantage of the Wi-Fi DirectSBD feature. Refer to Section III-B, SBD is a connectionlessdata transmission feature provided by Wi-Fi Direct. Since themalicious app has access to the entire Wi-Fi Direct API dueto overprivilege, it can utilize SBD to accomplish the offlineattack. The malicious app can register the SSID and the pass-word as a broadcast service. Any nearby device can discoverthis service if it scans following the SBD standard. This isexactly what Trudy’s smart phone is running. Trudy can pro-gram an app on the smart phone to periodically scan for nearbyservices. Because Trudy is in physical proximity to Alice andBob, Trudy’s smart phone has a great chance to discover theservice registered on both Alice and Bob’s smart phones.

There is another situation that the D2D network establishedby Alice and Bob’s smart phones is a hotspot network. Inthis scenario, the malicious app can still retrieve the pass-word of the network due to overprivileged framework design.Although Android does not provide an open-sourced APIfor the developer to get this information, the developers canstill use reflection to invoke a hidden system API called:getWiFiApConfiguration.

The next step of the offline attack is different from theprevious situation. Refer to the context in Section III-B,because Wi-Fi hotspot and Wi-Fi are not compatible and Wi-FiDirect requires the smart phone to enable Wi-Fi, the key infor-mation retrieved by the malicious app cannot get registeredby SBD on the smart phone which provides hotspot service.To make a successful offline attack, the malicious app canexploit the client smart phone because the client must havethe Wi-Fi turned on in order to connect to the hotspot. Thus,after the malicious app has got the key information, it patientlywaits for the connection from the client device. Once theclient has joined the hotspot network, it transmits the pass-word to the client device and the malicious app installed onthe client device will register the password using the SBDfeature. Trudy’s smart phone still scans for nearby servicesand eventually, it will discover the password registered on theclient device.

The offline key information leakage is now complete: Trudysteals the password that protects the D2D network establishedby Alice and Bob without their notice. The same attack logicapplies on both hotspot network and Wi-Fi Direct network onAndroid platform.

C. Avoidable Human-Involved Authentication Process

In previous sections, we introduced the human-involvedtwo-way authentication process during mobile D2D networkestablishment. Human involvement is one of the best solutionsto eliminate security risk in D2D network because a humancan physically identify the appropriate device and approve theconnection request. However, due to coarse-grained frame-work design, hackers can bypass the two-way authenticationprocess.

From Section IV-B, attackers can offline retrieve thepassword of the network. Now using the password, anydevice can join the network without undertaking the two-wayauthentication.

LIU et al.: SECURITY ANALYSIS OF MOBILE D2D NETWORK APPLICATIONS 2927

Fig. 5. Example of saved networks by a certain software.

Wi-Fi Direct network has extra protection mechanism in thestandard and Android has integrated the paring procedure onthe system level. However, Wi-Fi Direct supports two con-nection types: 1) D2D connection and legacy connection and2) human-involved paring only applies to the D2D connection.Because attackers have known the password to the GO, theycan join the Wi-Fi Direct network via a legacy connection,which is the same as to join a Wi-Fi AP. In this way, thehuman-involved paring protection will not get invoked on theAndroid smart phone.

There is an automated procedure that allows the Trudy’ssmart phone to join an encrypted Wi-Fi network program-matically. After Trudy’s smart phone has received the keyinformation from the previous attack, it follows the attackingoperations as described below. The procedure is a combinationof network APIs following the Wi-Fi connection logic.

The first step is to create the compatible network config-uration of the targeting network. The key points of the newconfiguration are the SSID, the password and the encryptionmethod. The second step is to save the new configuration tothe configuration list in the Android system. Android providessuch an API called: addNetwork. The third step is to reconnectto the currently active access point. We use reconnect becausethe network has been preconfigured and saved in the system.The network driver considers the target network as a past-connected network and it is capable of reconnecting to thataccess point when nearby. Fig. 5 shows an example of howAndroid distinguish the programmatically saved networks andthe typed-in saved networks. It marks the app’s name belowthe SSID.

Through those three steps, attacker circumvents the human-involved authentication process and joins the D2D networkwithout notifying the owner of the network.

D. Insecure Data Transfer

Developers have great freedom to choose how to transmitdata on the D2D network. Android neither specifies nor limitsthe protocol to make data transfer on the application level.Because file transfer is the most common application usingthe mobile D2D network, we focus our security analysis onthe protocol choices related to file transfers. In the followingparagraph we illustrate two popular file transfer protocols onD2D network and their security issues.

1) FTP on D2D Network: FTP can adapt to D2D networkand guarantee file transfer service. FTP also applies to a client–server model, but comparing to the direct TCP socket transfer,the server and client roles are inverted. Fig. 6 demonstrates

Fig. 6. FTP over D2D network and its work flow.

how D2D network utilizes FTP for local service. The twochannels, one on port 21 and the other on the feedback port,is an implementation of the FTP out-of-band design. FTP onmobile D2D network inherits the FTP features, such as pause,restart, and continue transfer. It also inherits the FTP log inmechanism. If the password is required by the server, the clienthas to log in to the FTP server before file transfer. If thepassword is not required by the server then any device in thenetwork could download the file from the server. FTP doesnot provide extra encryption mechanism to protect the datatransfer.

In Internet scenario, FTP normally combines with securesocket layer (SSL) and secure shell (SSH) to enhance securityon transport layer and application layer. In the offline scenario,because the network is assumed private and isolated, SSL andSSH are neglected; even the log in step in FTP is omitted toprovide best convenience to users. However, as descripted inprevious parts, intruders can exploit the D2D network with abenign-but-malicious app installed on users the cellphone. TheD2D network is not an absolute safe network even with strongpassword protection; therefore, unencrypted data suffers frommultiple threats when an intruder hacks into the network. Dueto limited access and variety of file transfer apps, we have notidentify an app in current market uses the offline FTP modelintroduced in this part. Nonetheless, we have verified it as apractical D2D file transfer model and examined its possiblesecurity vulnerabilities.

2) HTTP on D2D Network: The usage of HTTP on theD2D network is similar to FTP. Fig. 7 illustrates the implemen-tation of HTTP on D2D network. The server side is the smartphone providing data and the client side is the one receivingdata. On the server side, it binds port 80, which is the reservedHTTP port, on a server socket and waits for the connection.The client side initiates a TCP connection to port 80. If there isa successful connection established on port 80, then the serverdevice uses HTTP POST to post the file directory on its localserver. The server device also updates the post directory to theclient device through the same connection. The client devicecan access the file using HTTP GET. The server places thefile packets in the data field of the HTTP GET.

Similar to FTP, HTTP does not provide encryption mecha-nism to protect data. In the Internet scenario, HTTPS solvesthe encryption issue. HTTPS is a combination of HTTP onthe application layer and SSL on the transport layer. Inthe D2D network scenario, developers choose HTTP overHTTPS because HTTPS requires certificate authority (CA)but CA can only provide online service. In offline mode,

2928 IEEE INTERNET OF THINGS JOURNAL, VOL. 6, NO. 2, APRIL 2019

Fig. 7. HTTP over D2D network and its work flow.

TABLE IISTATISTICAL BREAKDOWN OF OUR ANALYSIS

CA is unreachable from the smart phone so the protec-tion mechanism may be burdensome. To guarantee the filetransfer feature, developer prefers HTTP over HTTPS butsending unencrypted data over HTTP is an insecure applicationdesign and Section IV discuss an example attacks targetingon HTTP.

IV. EMPIRICAL SECURITY ANALYSIS OF MOBILE

D2D NETWORK APPS

To understand how the security issues discussed inSection IV manifest in practice, we download four highestdownload file transfer apps from the Google Play Store andperformed in depth analysis. The total number of downloadsof those apps is over 1.5 billion, according to the staticsshown on both Google Play Store and Chinese Android PlayStore. Table II contains a statistical breakdown of our analy-sis on each application. Our analysis shows that all of thoseapps suffer from the framework design flaws discussed inSection IV.

A. Shareit

Shareit claims to be the number 1 file transfer tool in theworld. It has over 500 million users in China, 300 millionusers in India and over 1 billion users in world wide. Despitebeing such a popular application, its security implementation iscoarse-grained and we found multiple security issues. Beforewe can make an analysis on the network, we must identifywhich protocol it selects as the network basis. The default D2Dnetwork established by Shareit is via hotspot. Wi-Fi Direct fea-ture is included in the setting and user can enable it. However,Shareit marks Wi-Fi Direct as a Beta feature and it alters usersthe Beta version is unstable. Thus, we focus our analysis onthe hotspot network.

The hotspot network created by Shareit is an open networkby default. This is a risky design because anyone can access

Fig. 8. Shareit creates a WPA_PSK protect network and it is detected as aninsecure network.

Fig. 9. Shareit experiences the key information leakage problem.

Fig. 10. Context in the file params.txt.

the network regardless of the password. Shareit indeed offersan option for users to setup a customized password butthe security level is only WPA_PSK. As we mentioned inSection III, WPA_PSK has been proved not secure. Fig. 8shows the password protected network created by Shareit isdetected as a weak protection network. Fig. 9 shows Shareitexperiences key information leakage. A third party benign-but-malicious app can retrieve the same password created byShareit from the network framework.

On the application layer, Shareit chooses to use HTTPPOST and GET as the file transfer protocol instead of HTTPS.This design choice leaves data unencrypted and a packet cap-ture tool can catch the information transmitting on the network.To prove our point, we performed a file transfer using Shareit.The format of the file is .txt and the name of the file isparams.txt. This is a just a random .txt file we found in ourexperiment smart phone. The context of the file is just somerandom parameters as shown in Fig. 10.

During the file transfer, we started the packet capturetool. Our tool flagged each packet capture when it detectedupstream and downstream processed by a certain application.It marked the application and attached the details of the packetafterward. Fig. 11 illustrates the packet capture result. Theunencrypted data was exposed to our tool. Any smart phone

LIU et al.: SECURITY ANALYSIS OF MOBILE D2D NETWORK APPLICATIONS 2929

Fig. 11. Shareit packet capture result. The unencrypted data is exposed toour tool.

connected to this network could exploit similar attacks andsteal information from this network. We used a .txt file for abetter demonstration in our analysis. The attacker can recon-struct any type of file based on the intercepted data and thecorresponding file type, which is normally captured in theHTTP header.

B. Zapaya and Send Anywhere

Zapaya and Send Anywhere are very similar tools to Shareit.They also have a large number of users in world wide.According to the statistics on the official website and GooglePlay Store, they have almost 510 million users globally. Weperformed the same attack on them and observed the samevulnerabilities as Shareit.

C. SuperBeam

SuperBeam is a Wi-Fi Direct-based D2D file transfer tool.According to the statistics from Google Play Store, it has 1050million downloads. Refer to the architectural design of Wi-FiDirect in Section III, the network is automatically encryptedby WPA2_PSK and there is an additional system level human-involved paring protection. Thus, the network created bySuperBeam is essentially safer than the network created byprevious three applications. However, due to coarse-grainedframework design, SuperBeam also has key information leak-age issue and attackers can bypass the paring authenticationprocedure with a legacy connection.

SuperBeam utilizes HTTP on the application layer to handlefile transfer. The implementation of HTTP is slightly differ-ent from previous three applications. Other than sending andreceiving data exclusively through the application, SuperBeamoffers a feature that allows connected devices to download thefile from the Web browser. We exploit this feature and con-struct a new attack model to steal the file from the HTTPserver. We will demonstrate such a combinational attack inSection VI.

V. PROOF-OF-CONCEPT ATTACKS

We show three concrete ways in which we combine var-ious security design flaws and developer-bugs discussed inSections III–V to weaken mobile D2D network security. Wefirst present an offline attack that exploits password pro-tected network with a benign-but-malicious app which requests

Fig. 12. Top left: Hack SuperBeam catches the group formation event andregisters the key information on SBD. Top right: Trudy steals the key infor-mation of the network through an offline attack. Bottom: Hack SuperBeamsaves the network configuration, allowing Trudy’s smart phone to reconnectto Alice’s phone.

minimum permissions from Android system. We then show anattack that steal the file from a smart phone which intents toestablish file transfer service with a peer. In the third attack weshow an intruder in the network can eavesdrop on the networkand capture data during a file transfer.

A. Offline Network Hacking Attack

The threat model we use in this attack is the same aswhat we introduced in Section IV-B. We setup three smart-phones. Two of them are Alice and Bob and the otherone is Trudy. Alice and Bob are trying to establish a D2Dnetwork using SuperBeam and Trudy will hack into thenetwork.

On all three smart phones, we installed the benign-but-malicious app and we call it Hack SuperBeam. This appli-cation is programmed thoroughly using open-sourced APIprovided by Android and none of those three smart phonesare rooted devices. They are off-the-shell smart phones runningthe primitive Android operating system.

Hack SuperBeam exploits the overprivileged framework. Itseems to have a benign behavior because it does not triggerany sensitive system alarm whatsoever. It requests a few mostcommon permissions from the system as majority applicationdoes.

Hack SuperBeam follows the attack logic described inFig. 4. To snap the network change events, the first step isto register the system actions that reflects the change of thenetwork and connections. The second step Hack SuperBeamtakes is to get the key information of the network. Fig. 12demonstrates Hack SuperBeam receives the group establish-ment event. After group formation, Hack SuperBeam uses theAPI to retrieve group information. The third step is to reg-ister the captured SSID and password to the connectionlessbroadcast service using the SBD feature. The final step isto make a legacy connection to the GO. Fig. 12 shows thenetwork configuration is saved by Hack SuperBeam, indi-cating the final step before connection. Thereafter, Trudy’sdevice can reconnect to Alice’s phone with a legacyconnection.

2930 IEEE INTERNET OF THINGS JOURNAL, VOL. 6, NO. 2, APRIL 2019

Fig. 13. Left: Trudy can download the image file displayed on his smartphone using Hack SuperBeam. Right: packet capture on SuperBeam revealsthe unencrypted data.

B. File Stealing Attack

In the previous section, we exploit an offline network hack-ing attack. Trudy is now in the D2D network created by Aliceand Bob and he can download the file from Alice.

SuperBeam offers a function for the peers to download thefile on a Web browser. Trudy is now a peer in the networkand Hack SuperBeam can exploit this feature and downloadthe sharing files.

SuperBeam post the context of the sharing files on its localserver. The address of the files is 192.168.49.1:8080. At thispoint, Trudy can download the file and complete the file steal-ing attack. Fig. 13 demonstrates the webview and URL in HackSuperBeam that allows Trudy to download the file.

C. Packet Eavesdropping

Packet eavesdropping also applies to SuperBeam becauseit does not encrypt data throughout the file transfer process.After Trudy hacked into the network, he can use a packetcapture tool and eavesdrop on the network. The unencrypteddata in Fig. 13 is from the .txt file Alice sends to Bob. Trudycan intercept the data and steal the information.

VI. IMPROVEMENT SUGGESTIONS

We discuss some lessons learned from the analysis of themobile D2D network on Android that we believe to be broadlyapplicable to mobile D2D network framework design. We alsoprovide some improvement suggestions.

1) Extra Permission to Access D2D Network: Android doesnot provide dedicate permissions to access D2D network. Anyapplication installed on the device has equivalent access tothe D2D network, even though it does not need to use thisfeature. This causes overprivilege issues and it becomes thefundamental vulnerability to other threats. We suggest Androidplace dedicated permissions to control the accessibility ofD2D network, including Wi-Fi hotspot and Wi-Fi Direct. Thiscan avoid irrelevant third party app retrieving key informationabout the network.

2) Key Network Information Protection: Key informationabout the network should have restricted access. If one appli-cation is using the D2D feature and the framework shouldprevent another application access the key information aboutthe network. If both applications want to share the D2D

network feature, the user must get altered and authorize thisrequest.

3) Keep Track of the Number of Clients: The host of thenetwork, the CH or the GO, should keep track of the numberof clients in the network to prevent intruders. The host devicecan read its ARP table and determine how many devices arereachable in the network. If there is an unrecognized devicejoins the ARP table, the host device should pause the D2Dservice immediately and alert the user.

4) Data Encryption: There are multiple ways to solve thisissue. Developers can preinstalled a shared key in the appli-cation to encrypt data. The preinstalled key can also supportDiffie–Hellman to establish a temporary shared key for encryp-tion. The purpose of the encryption key is to provide a secureoffline transportation layer so data transmission using HTTPand FTP can be secure.

The security issue due to framework overprivilege is offundamental importance. Since it is a middleware securityproblem, the solution to eliminate the vulnerability requiresthe effort from both industrial and academic sides. The solu-tion we proposed in this paper is to avoid such security issueson the application level. App developers can take our adviceand make corresponding changes to patch the security bugs.The fixes seem to be simple but the problem is not supposed tobe in the middleware in the first place. It is not the developer’sresponsibility to follow a specific setup of APIs to make theirapplication safe. Nonetheless, we pointed out a nonobviousarchitectural issue in designing a secure mobile D2D networkto which all developers must pay attention, and we give out asolution to avoid the design issue.

VII. RELATED WORK

There are a number of pioneering research works studiedmultiple aspects of D2D communication. Among them, [7]developed an analytical model for analyzing the cover-age probability and ergodic rate of users in the cellularnetwork. Cao et al. [6] studied the resource allocation problemfor minimizing the end-to-end delay for D2D communica-tions in the vehicular network. Liu et al. [16] presented acomprehensive survey of available D2D research works, andoutlined several open research problems. As to the securityaspect, Shen et al. [22] proposed a key establishment protocolfor initial trust establishment in a WiFi Direct D2D network,Haus et al. [11] presented an extensive review of the state-of-the-art solutions for enhancing security and privacy in D2Dcommunication. The review spanned across a variety of D2Dprospects, such as network communication, peer discovery,proximity services, and location privacy. Haus et al. [11] alsoprovided a detailed discussion on D2D privacy. It summarizedand compared the existing solutions according to security andprivacy requirements.

Since this paper focuses on IEEE 802.11-based D2D com-munication, the thorough studies of IEEE 802.11 securityprotocols are related to this paper. Lashkari et al. [15]explained the structure and problems of WPA and WPA2.Adnan et al. [1] made a comparison between WPA andWPA2, and correlated the two with respect to performance.

LIU et al.: SECURITY ANALYSIS OF MOBILE D2D NETWORK APPLICATIONS 2931

Raju and Nair [21] considered vulnerabilities like open natureof communication channel, lack of confidentiality, weakencryption methods, etc., in a Wi-Fi hotspot and proposed asecurity protocol that ensured individual confidentiality duringthe communication.

Although this paper focuses on the security issue in Wi-Firelated D2D systems, our group has also reviewed worksrelated to the mobile D2D system based on Bluetooth technol-ogy. Bluetooth related technologies have been widely adaptedin wearable devices, such as watches and wristbands. Thesecurity issues inherent in Bluetooth are largely due to theprocess of pairing one device to another. Bluetooth paringis still subject to Man-in-the-Middle attacks, even after thedevices are paired. The biggest factor in Bluetooth vulner-abilities is the version of Bluetooth that is being used, andthe security of communications between devices is only asstrong as the weakest link, i.e., the device with the oldest(weakest) version. Such vulnerabilities include coarse PINmanagement, unlimited challenge requests, and weak streamcipher [20], [23].

Some groups had studied the security of D2D networkfrom smart phone applications. Bai et al. performed a securityanalysis on Apple’s major ZeroConf components and foundout it is mostly unprotected. IOS system is a close-sourcedenvironment and this group took the challenge and con-cluded ZeroConf systems like AirDrop did not have securityguaranteed [3], [19].

The security of Android system is under strict scrutiny. TheAndroid operating system uses the permission-based modelwhich allows applications to access user information, systeminformation, device information, and external resources of thesmart phone. Misuse of app permissions is one of the main rea-sons leading to the overprivilege in the mobile D2D network.Studies of Android security issues presented in [10], [12],[13], and [25] provided a systematic study of the Android secu-rity architecture. Buhov et al. [5], Kawamoto et al. [14], andLiu et al. [17] focused on the current issues related to misuseof the network protocols in Android such as HTTPS and SSL.

Vulnerabilities in connections between proximatedevices have been studied extensively. Haus et al. [11]and Xia et al. [25] identified three security threats due to:1) direct wireless connections; 2) mobility of end users; and3) privacy issues in social applications. The greater the num-ber of devices that adopt D2D communication, the greaterthe interest of adversaries to attack these networks [23].According to recent study [19], security and privacy are openissues for D2D.

VIII. CONCLUSION

We performed an empirical security evaluation of themobile D2D framework on Android operating system.Analyzing mobile D2D network was challenging because therewere multiple mechanisms to establish a D2D network onAndroid and each of them uses distinct security protections.Additionally, the apps installed on Android were close-sourcedindividual modules so we did not know how file transferservice was implemented on the application level.

We performed an overprivilege analysis of four most pop-ular D2D file transfer apps to determine how well the mobileD2D framework protects user’s information and privacy. Thefour apps have over 1.5 billion users combined. We discovered:1) all those apps suffer from the overprivilege issue due tocoarse-grained network framework; 2) key information leakageis a prevailing threat; 3) the system-enforced human-involvedauthentication process is avoidable; and 4) unencrypted datatransfer over network is insecure. We combined these designflaws with other vulnerabilities and constructed three proof-of-concept attack to: 1) hack into a D2D network; 2) steala file from a network; and 3) eavesdropping on a network tocapture unencrypted data. At the end of this paper, we summa-rized the lessons from our analysis and provided improvementsuggestions.

REFERENCES

[1] A. H. Adnan et al., “A comparative study of WLAN security protocols:WPA, WPA2,” in Proc. IEEE Int. Conf. Adv. Elect. Eng. (ICAEE), 2015,pp. 165–169.

[2] A. Asadi, Q. Wang, and V. Mancuso, “A survey on device-to-devicecommunication in cellular networks,” IEEE Commun. Surveys Tuts.,vol. 16, no. 4, pp. 1801–1819, 4th Quart., 2014.

[3] X. Bai et al., “Apple ZeroConf holes: How hackers can steal iPhone pho-tos,” IEEE Security Privacy, vol. 15, no. 2, pp. 42–49, Mar./Apr. 2017.

[4] O. Bello and S. Zeadally, “Intelligent device-to-device communicationin the Internet of Things,” IEEE Syst. J., vol. 10, no. 3, pp. 1172–1182,Sep. 2016.

[5] D. Buhov, M. Huber, G. Merzdovnik, E. Weippl, and V. Dimitrova,“Network security challenges in Android applications,” in Proc. IEEEInt. Conf. Availability Rel. Security (ARES), 2015, pp. 327–332.

[6] X. Cao, L. Liu, Y. Cheng, L. X. Cai, and C. Sun, “On optimal device-to-device resource allocation for minimizing end-to-end delay in VANETs,”IEEE Trans. Veh. Technol., vol. 65, no. 10, pp. 7905–7916, Oct. 2016.

[7] J. Dai, J. Liu, Y. Shi, S. Zhang, and J. Ma, “Analytical modelingof resource allocation in D2D overlaying multihop multichanneluplink cellular networks,” IEEE Trans. Veh. Technol., vol. 66, no. 8,pp. 6633–6644, Aug. 2017.

[8] Z. Degui and Y. Geng, “Content distribution mechanism in mobile P2Pnetwork,” J. Netw., vol. 9, no. 5, p. 1229, 2014.

[9] G. Ding and B. Bhargava, “Peer-to-peer file-sharing over mobile adhoc networks,” in Proc. IEEE Annu. Conf. Pervasive Comput. Commun.Workshops, Orlando, FL, USA, 2004, pp. 104–108.

[10] P. Faruki et al., “Android security: A survey of issues, malware pen-etration, and defenses,” IEEE Commun. Surveys Tuts., vol. 17, no. 2,pp. 998–1022, 2nd Quart., 2015.

[11] M. Haus et al., “Security and privacy in device-to-device (D2D) com-munication: A review,” IEEE Commun. Surveys Tuts., vol. 19, no. 2,pp. 1054–1079, 2nd Quart., 2017.

[12] Y. J. Jia, Q. A. Chen, Y. Lin, C. Kong, and Z. M. Mao, “Open doors forbob and mallory: Open port usage in Android apps and security impli-cations,” in Proc. IEEE Eur. Symp. Security Privacy (EuroSP), 2017,pp. 190–203.

[13] S. Karthick and S. Binu, “Android security issues and solutions,” in Proc.IEEE Int. Conf. Innov. Mech. Ind. Appl. (ICIMIA), 2017, pp. 686–689.

[14] Y. Kawamoto et al., “A feedback control-based crowd dynamics man-agement in IoT system,” IEEE Internet Things J., vol. 4, no. 5,pp. 1466–1476, Oct. 2017.

[15] A. H. Lashkari, M. M. S. Danesh, and B. Samadi, “A survey on wirelesssecurity protocols (WEP, WPA and WPA2/802.11i),” in Proc. IEEE Int.Conf. Comput. Sci. Inf. Technol. (ICCSIT), 2009, pp. 48–52.

[16] J. Liu, N. Kato, J. Ma, and N. Kadowaki, “Device-to-device communi-cation in LTE-advanced networks: A survey,” IEEE Commun. SurveysTuts., vol. 17, no. 4, pp. 1923–1940, 4th Quart., 2015.

[17] J. Liu, Y. Kawamoto, H. Nishiyama, N. Kato, and N. Kadowaki,“Device-to-device communications achieve efficient load balancing inLTE-advanced networks,” IEEE Wireless Commun., vol. 21, no. 2,pp. 57–65, Apr. 2014.

[18] K. Liu et al., “Development of mobile ad-hoc networks over Wi-Fidirect with off-the-shelf Android phones,” in Proc. IEEE Int. Conf.Communications (ICC), 2016, pp. 1–6.

2932 IEEE INTERNET OF THINGS JOURNAL, VOL. 6, NO. 2, APRIL 2019

[19] S. U. Masruroh, I. Saputra, and Nurhayati, “Performance evaluationof instant messenger in Android operating system and iPhone operat-ing system,” in Proc. IEEE Int. Conf. Cyber IT Service Manag., 2016,pp. 1–6.

[20] N. B.-N. I. Minar and M. Tarique, “Bluetooth security threats and solu-tions: A survey,” Int. J. Distrib. Parallel Syst., vol. 3, no. 1, p. 127,2012.

[21] L. K. Raju and R. Nair, “Secure hotspot a novel approach to secure pub-lic Wi-Fi hotspot,” in Proc. IEEE Int. Conf. Control Commun. Comput.India, 2015, pp. 642–646.

[22] W. Shen, B. Yin, X. Cao, L. X. Cai, and Y. Cheng, “Secure device-to-device communications over WiFi direct,” IEEE Netw., vol. 30, no. 5,pp. 4–9, Sep./Oct. 2016.

[23] M. Wang and Z. Yan, “A survey on security in D2D communications,”Mobile Netw. Appl., vol. 22, no. 2, pp. 195–208, 2017.

[24] S. Wang et al., “Opportunistic routing in intermittently connectedmobile P2P networks,” IEEE J. Sel. Areas Commun., vol. 31, no. 9,pp. 369–378, Sep. 2013.

[25] X. Xia, C. Qian, and B. Liu, “Android security overview: A system-atic survey,” in Proc. IEEE Int. Conf. Comput. Commun. (ICCC), 2016,pp. 2805–2809.

Kecheng Liu (S’15) received the B.E. degreein electrical and computer engineering fromthe University of Illinois at Urbana–Champaign,Champaign, IL, USA, in 2013, and the M.S. degreein computer engineering from the Illinois Instituteof Technology, Chicago, IL, USA, where he is cur-rently pursuing the Ph.D. degree at the Departmentof Electrical and Computer Engineering.

His current research interests include Internet ofThings system security and device-to-device networksecurity.

Wenlong Shen (GS’13–M’16) received the B.E.degree in electrical information engineering fromBeihang University, Beijing, China, in 2010, theM.S. degree in telecommunications from theUniversity of Maryland at College Park, CollegePark, MD, USA, in 2012, and the Ph.D. degree inelectrical and computer engineering from the IllinoisInstitute of Technology, Chicago, IL, USA, in 2018.

His current research interests includes informa-tion security, D2D communications, and wirelessnetworking.

Yu Cheng (S’01–M’04–SM’09) received the B.E.and M.E. degrees in electronic engineering fromTsinghua University, Beijing, China, in 1995 and1998, respectively, and the Ph.D. degree in electri-cal and computer engineering from the University ofWaterloo, Waterloo, ON, Canada, in 2003.

He is currently a Full Professor with theDepartment of Electrical and Computer Engineering,Illinois Institute of Technology, Chicago, IL, USA.His current research interests include wirelessnetwork performance analysis, network security, big

data, cloud computing, and machine learning.Dr. Cheng was a recipient of the Best Paper Award at QShine 2007,

the IEEE ICC 2011, the Runner-Up Best Paper Award at ACM MobiHoc2014, the National Science Foundation CAREER Award in 2011, and the IITSigma Xi Research Award in the Junior Faculty Division in 2013. He hasserved as the Symposium Co-Chair for IEEE ICC and IEEE GLOBECOM,and the Technical Program Committee Co-Chair for WASA 2011 and ICNC2015. He was a founding Vice Chair of the IEEE ComSoc TechnicalSubcommittee on Green Communications and Computing. He was an IEEEComSoc Distinguished Lecturer from 2016 to 2017. He is an Associate Editorfor the IEEE TRANSACTIONS ON VEHICULAR TECHNOLOGY.

Lin X. Cai (GS’09–M’10) received the M.A.Sc. andPh.D. degrees in electrical and computer engineer-ing from the University of Waterloo, Waterloo, ON,Canada, in 2005 and 2010, respectively.

She was a Post-Doctoral Research Fellow withthe Electrical Engineering Department, PrincetonUniversity, Princeton, NJ, USA, in 2011. Shejoined the Huawei U.S. Wireless Research andDevelopment Center, as a Senior Engineer in 2012.She has been an Assistant Professor with theDepartment of Electrical and Computer Engineering,

Illinois Institute of Technology, Chicago, IL, USA, since 2014. Her currentresearch interests include green communication and networking, broadbandmultimedia services, and radio resource and mobility management.

Dr. Cai was a recipient of the Post-Doctoral Fellowship Award from theNatural Sciences and Engineering Research Council of Canada in 2010, theBest Paper Award from IEEE Globecom 2011, and the NSF Career Awardin 2016. She is an Associate Editor of IEEE Network Magazine and theIEEE TRANSACTION ON WIRELESS COMMUNICATIONS and the Co-Chairfor IEEE conferences.

Qing Li (M’03) is a Vice President of Engineeringwith the Network Protection Products Business Unit,Symantec Cooperation, Mountain View, CA, USA.He served as the Chief Scientist with Blue CoatSystems, Sunnyvale, CA, USA, where he is a well-known V1.0 technology and product innovator. He isan industry veteran with over 20 years of experience,with 28 issued patents and many more pending. Heis a published author of five first-of-their-kind books,by Springer-Verlag, Morgan Kaufmann, and Wiley.His books have been translated into multiple foreign

languages and are serving as reference texts in universities and in industryaround the world.

Sheng Zhou (GS’05–M’11) received the B.E.and Ph.D. degrees in electronic engineering fromTsinghua University, Beijing, China, in 2005 and2011, respectively.

In 2010, he was a Visiting Student with theWireless System Lab, Department of ElectricalEngineering, Stanford University, Stanford, CA,USA, for five months. From 2014 to 2015, hewas a Visiting Researcher with Central ResearchLaboratory, Hitachi Ltd., Tokyo, Japan. He is cur-rently an Associate Professor with the Department

of Electronic Engineering, Tsinghua University. His current research interestsinclude cross-layer design for multiple antenna systems, mobile edge com-puting, and green wireless communications.

Zhisheng Niu (M’98–SM’99–F’12) received thegraduation degree from Beijing Jiaotong University,Beijing, China, in 1985, and the M.E. andD.E. degrees from the Toyohashi University ofTechnology, Toyohashi, Japan, in 1989 and 1992,respectively.

From 1992 to 1994, he was with FujitsuLaboratories Ltd., Tokyo, Japan. In 1994, he joinedTsinghua University, Beijing, China, where he is cur-rently a Professor with the Department of ElectronicEngineering. His current research interests include

queueing theory, traffic engineering, mobile Internet, radio resource manage-ment of wireless networks, and green communication and networks.

Dr. Niu was a recipient of the Outstanding Young Researcher Award fromthe Natural Science Foundation of China in 2009 and the Best Paper Awardfrom the IEEE Communication Society Asia–Pacific Board in 2013. He hasserved as the Chair of the Emerging Technologies Committee from 2014to 2015, the Director for Conference Publications from 2010 to 2011, andthe Director for the Asia–Pacific Board from 2008 to 2009 of the IEEECommunication Society, and is currently serving as the Director for OnlineContents from 2018 to 2019 and an Area Editor for the IEEE TRANSACTIONS

ON GREEN COMMUNICATIONS AND NETWORKING. He was also selected asa Distinguished Lecturer of the IEEE Communication Society from 2012 to2015 and IEEE Vehicular Technologies Society from 2014 to 2018. He is aFellow of the IEICE.