Are Wearables Ready for Secure and Direct Internet Communication?

[past➔Future]

Harini Kolamunna, Jagmohan Chauhan and Yining Hu University of New South Wales, Australia Kanchana Thilakarathna University of Sydney, Australia Diego Perino Telefonica Research, Barcelona, Spain Dwight Makaroff University of Saskatchewan, Canada Aruna Seneviratne University of New South Wales, Australia

Editor: Geoffrey Challen ARE WEARABLES READY FOR SECURE AND DIRECT INTERNET COMMUNICATION?

Recent advances in wearable technology tend towards standalone wearables. Most of today’s wearable devices and applications still rely on a paired smartphone for secure Internet communication, even though many current generation wearables are equipped with Wi-Fi and 3G/4G network interfaces that provide direct Internet access. Yet it is not clear if such communication can be efficiently and securely supported through existing protocols. Our findings show that it is possible to use secure and efficient direct communication between wearables and the Internet.

earables such as smartwatches for processing, storage, and visualization. direct Internet connection capability. and smartglasses are becoming Furthermore, there are many popular apps Therefore, this article attempts to answer increasingly popular as they that transfer data from cloud servers to the critical question – “Are wearables show promise in providing a number of wearables to provide real-time notifications. ready for secure and direct Internet attractive and useful services [1]. Wearables Due to the sensitivity of the transferred communication?” – by means of real are equipped with sophisticated sensors personal data, secure communication experiments with modern wearables. and connectivity options that are capable protocols must be used. Our study on In this paper, we first analyze the of collecting personal data to support most popular wearable apps shows that the Internet communication methods, personalized services, such as fitness and majority of today’s wearable apps rely on a protocols, amount of data, and communi- health apps. More often than not, this paired smartphone via Bluetooth to provide cation frequencies for the most popular

Photo, istockphoto.com Photo, information is transferred to cloud servers secure Internet communication despite smartwatch apps to profile current wearable

September 2017 | Volume 21, Issue 3 GetMobile 5 [past➔Future]

CloudCloud NodeCloud Node Node

MobileMobile data/WiFiMobile data/WiFi data/WiFi MobileMobile data/WiFiMobile data/WiFi data/WiFi WiFiWiFiWiFi WiFiWiFiWiFi

BT BT BT

(a) Direct communication. (b) Relaying through the paired (c) Relaying through a cloud server smartphone via Bluetooth. (Wear Cloud) and the paired smartphone via Wi-Fi.

FIGURE 1. Methods of Internet communication for smartwatch apps.

app-generated traffi c. Th e results show Hangouts, Weather, Google) have been via WiFi or cellular data. In Method-2, that smartwatches are not yet considered already installed as default apps, and the next the smartwatch communicates with the as standalone devices, for the following three apps (To-Do List, Shazam, Runtastic) smartphone counterpart of the same app via possible reasons: 1) enabling secure were downloaded from Google Play. To gain Bluetooth and relies on the smartphone app communication from the wearables is insight on communications, we run tcpdump for any external communication. Method-3 considered a signifi cant burden due to the and Bluetooth HCI Snoop log on each device. is used as long as both devices have Internet lower capabilities of wearables compared to We mimicked typical usage of these apps connectivity. Instead of communicating a smartphone; and/or 2) relaying through and captured incoming and outgoing data directly with the end servers, the smartwatch a smartphone is considered more effi cient from both the smartphone and smartwatch is connected to a trusted cloud server, Wear (in terms of energy and time) than direct for two scenarios; i) turning-off Bluetooth Cloud, provided by Google [2]. Wear Cloud Internet communication. Th erefore, we while turning-on Wi-Fi on the smartwatch, relays all requests from wearables to the investigate the impact of these two factors and ii) turning-on Bluetooth on both the respective smartphone counterpart apps, on wearables in comparison to a smartphone smartwatch and smartphone (Wi-Fi of and then the smartphone communicates through a series of experiments. Th e the wearable is turned off automatically). with the targeted server and relays data back experimental results show that secure, Smartphone Wi-Fi is turned on at all to the wearable through Wear Cloud. standalone apps and platforms can be times. We investigated the apps’ Internet We observed that the default practically and effi ciently realized on current communication methods and protocols in communication mode of choice for all wearables and, thus, we provide suffi cient both of the scenarios. We also measured the analyzed apps is Method-2, i.e. smartphone evidence to app developers to motivate them amount of data and frequency of Internet relaying, irrespective of the availability to create standalone apps and platforms in communication for the most popular of a direct Internet connectivity. When the foreseeable future. communication method. Bluetooth of the wearable is turned-off , only 2 apps (Google Fit, Google Translate) were INTERNET COMMUNICATION Communication modes of capable of communicating directly with the FROM SMARTWATCHES Android wearables servers using Method-1. Th e remaining 8 Measurement methodology: We used an Current smartwatch apps leverage three apps attempted to leverage Method-3, which LG Urbane smartwatch running Android modes of Internet communications is subjected to the Internet connectivity Wear and a Nexus 4 smartphone running supported by Android; Method-1: Direct of the paired smartphone. When the Android 5.1.1. We considered the 10 most Communication; Method-2: Relaying paired smartphone is not connected to popular Android wear apps in Google Play.1 through the paired smartphone via Internet, these eight apps do not support Seven apps out of the 10 (Google Fit, Bluetooth; Method-3: Relaying through a functionalities that require Internet Google Translate, Reminders, Google Keep, cloud server (Wear Cloud) and the paired connectivity. Th is is a signifi cant drawback smartphone via Wi-Fi (see Figure 1). of the current wearable eco-system, which 1 https://play.google.com/store/apps/category/ In Method-1, the smartwatch directly essentially constrains the potential of ANDROID_WEAR?hl=en communicates with the targeted servers wearable devices. In the case of Android,

6 GetMobile September 2017 | Volume 21, Issue 3 [past➔Future]

transferred from and to each app, and TABLE 1. Data sizes, data transfer direction and communication frequencies in Internet communication the frequency of the communication. We selected Method-2 as it is common for all App Name Size of the transferred Direction of Communication 10 apps and measured the total amount of application data from data transfer frequency application layer data transmitted between and to servers the server and smartphone. The two Runtastic 1 KB Upload Once per every fitness-tracking applications (Google Fit 90 seconds and Runtastic) transfer data in the range Google Fit 1 KB Upload Once per every of 1 KB. However, these connections are 10 minutes periodic (i.e., Google Fit transfer in every 10 minutes, Runtastic transfer in every Google 10 KB Download 90 seconds) and eventually transfer a Shazam 16 KB Upload/Download larger amount of data. All the other apps To-Do List 20 KB Upload communicate on demand and transfer more than 10 KB of data for each connection. Google Keep 26 KB Upload As requested Reminders app transfers the highest amount Google Translate 44 KB Upload/Download of data, which is more than 100 KB. Hangouts 50 KB Upload/Download Not all of the wearable apps are designed Weather 50 KB Download to collect data and upload to the Internet. There are apps that are purely designed Reminders 112KB Upload/Download to download data from the Internet, such as Weather and Google. This downloaded data is not required to be synced with the smartphone. Also, Google Translate, the developer documentation encourages are available for the transfer of web objects. Reminders, Google Keep, Google Fit and developers to use Wearable Data Layer HTTP is the standard original Web Traffic Hangouts apps perform both uploads and APIs, but these APIs do not support direct protocol. It does not provide end-to-end downloads in certain cases. However, these communication, and this hiding the true security. Security is provided by the HTTPS apps are linked with the user’s Google communication mode from the developer. protocol [3]. Recently Google has released account; therefore, if the smartphone is If a developer wants an app to communicate versions of the QUIC (Quick UDP Internet connected to the Internet, the data can with the Internet directly, the developer Connections) protocol, which focuses on be retrieved by synchronizing with the should use basic APIs. low latency for connections and transport Google account. Similarly, each user has In the relayed communication (Method-2 data, and was designed to provide TLS/ their own account for To-Do List, Shazam and Method-3) the counterpart app for the SSL equivalent security [4]. Although and Runtastic apps that allows data to be smartphone behaves in different ways for the smartphone’s connections with the synchronized if the user logs into their different apps. The counterpart app either Internet use HTTPS, HTTP2 and QUIC account from the smartphone. Computation displays statistics, does some processing to protocols, all the direct connections from for other apps, such as Google Translate, the data before transferring, or just relays the smartwatch only use HTTPS. Reminders, and Google Keep can also data to/from Internet servers. As examples, At the data link layer, the smartwatch’s be moved to the cloud and bypass the Google Fit and Runtastic in both devices connections with the smartphone are smartphone. Thus, all the analyzed apps measure, display and exchange data before established via Bluetooth Basic Rate/ can take advantage from direct and secure Internet communication. Also, Google Enhanced Data Rate (BR/EDR) in all Internet connectivity rather than always Translate, Reminders, and Google Keep the apps, referred to as Bluetooth Classic relaying through the smartphone. process data received from the smartwatch (BT-classic). Surprisingly, no apps utilize However, leveraging the smartphone to perform voice recognition. Moreover, Bluetooth Low Energy (BLE) for such for Internet communication is the chosen Reminders, Google Keep, Hangouts, To-Do communication, although it is intuitive to method for most current apps, despite List, and Shazam store the statistics and use a protocol that consumes low energy not being a functional requirement. display the data received before sending for wearables [5]. We will investigate the The observed traffic profiles of wearable back to the smartwatch. On the other hand, consequences of using BLE and BT-Classic apps in terms of transmitted amount of Google and Weather apps are using the in the remainder of this article. data, frequency of communication and smartphone just as a relay device. For a deeper understanding of current connection duration make a strong case for wearable traffic, we then investigated utilizing direct, secure connectivity. Thus, Communication protocols the amount of data and frequency of we experimentally evaluate the practical We also investigated the utilization of communication from the smartwatch apps, feasibility of utilizing direct and secure communication protocols in wearable- while the app is running in the foreground. Internet communication on wearables in Internet communication. Several protocols Table 1 shows the total number of bytes the remainder of this article.

September 2017 | Volume 21, Issue 3 GetMobile 7 [past➔Future]

SECURITY-PERFORMANCE the processing overhead of encrypting data TRADE-OFF OF DIRECT increases the data transfer time and hence COMMUNICATION the energy consumption. Although secure In this section, we analyze the cost of communication is more energy expensive, enabling secure Internet direct communica- the next section will show that it is still tion with a smartwatch and a smartglass as more energy efficient than leveraging the they represent two most advanced wearable smartphone as a relay. categories of devices. Specifically, we measure Further, we investigate the benefits energy, time and downloaded data overhead of using the modern HTTP extensions, associated with HTTPS in a controlled ex- like HTTP2, which enables long-lived perimental environment and compare it with (a) Normalized energy consumption connections and amortize the cost of HTTP and a smartphone as baselines. for different file sizes. re-establishing the TLS connections, as the TLS handshake overhead is more Measurement methodology: We added significant for smaller data transfers. -5 1.8 a Google Glass Explorer edition running Connection termination However, the long-lived connections 1.6 Data exchange Android XE 18.11 to the previous hardware/ TLS handshake consume additional energy during the idle 1.4 TCP handshake software configurations. We developed an connection time because of the elevated 1.2 Android app for all three platforms that power state of devices. Figure 3 illustrates 1 simply fetches objects from a given address the analyses of energy saving offered by 0.8 using either HTTP or HTTPS (Method-1). keeping the connection alive for different 0.6 We downloaded objects of multiple sizes traffic patterns and device types, which is 0.4 (1 KB, 10 KB, 100 KB and 500 KB) from an based on measured energy consumption 0.2 Apache web server connected to the local of different phases of connection and

Normalized energy consumption x 10 0 network with end-to-end security (HTTPS) Watch Glass Phone periodic 1 KB downloads. Long-lived and without security (HTTP). To measure (b) Energy consumed: 1 KB download. connections are beneficial only when idle the transfer times and downloaded bytes, energy consumption is relatively lower and we run a tcpdump on each device. Energy the time interval between two transfers are -5 1.8 consumption is measured with a Monsoon Connection termination smaller (color shades of the figure show the 1.6 Data exchange power monitor2 directly connected to each TLS handshake percentage of energy saving). For a typical 1.4 TCP handshake device via USB. Due to the significant differ- Wi-Fi idle power consumption of 200mW, 1.2 ence in battery capacity among the compared long-lived connections are beneficial only 1 devices, the absolute energy consumption is if the time interval is less than 500 ms for 0.8 normalized by the battery capacity. a 1 KB data transfer. The time interval 0.6 Figure 2(a) depicts the normalized and idle energy values that are above the 0.4 energy consumption for downloading web 0% curve will not benefit from long-lived 0.2 objects. Energy consumption increases with connections. Therefore, a typical app will

Normalized energy consumption x 10 0 object size in all cases due to the longer Watch Glass Phone not benefit from keeping a connection alive transfer duration, but the overhead of (c) Data transfer time: 1 KB download. as per the observed traffic profiles in the HTTPS is more apparent for smaller object previous section. sizes. Normalized energy consumption for FIGURE 2. Cost of handling security. both wearables is significantly greater than COST OF DIRECT VS. for the smartphone. In terms of downloaded RELAYED COMMUNICATION data, there is an increment of 5421 bytes In this section, we evaluate the relative during the TLS handshake phase, in As the sizes of the majority of the time and energy efficiency of leveraging addition to the ~0.2% increment in payload objects transferred between wearables direct Internet communication. Relayed due to encryption. These observations are and the Internet are at least a few KBs as communication can be established via common for all the devices as long as the shown earlier, we further quantify the BT (i.e. BT-Classic, BLE) or Wi-Fi as same TLS parameters are used. However, the energy consumption for each phase of the shown in Figure 1. Wi-Fi relaying, as in ratio between HTTPS/HTTP for wearables communication for 1KB object size. Figure Method-3, incurs significant extra delays is comparable with the smartphone. A 2(b) and 2(c) illustrate that the majority and energy consumption compared to comprehensive analysis of the impact of of both energy and time is consumed the other methods as it requires two secure communication on wearables is during the TLS handshake. Due to the key communications with the Internet presented in our earlier publication [6]. generation process, the time consumption (i.e., smartwatch to smartphone via Wear and energy footprint of the TLS handshake Cloud and Smartphone third party server). 2 https://www.msoon.com/LabEquipment/ is significant in comparison to the amount of Therefore, Wi-Fi relaying is not considered PowerMonitor data generated in all three devices. Moreover, for this analysis.

8 GetMobile September 2017 | Volume 21, Issue 3 [past➔Future]

FIGURE 3. Percentage energy saving by long-lived connections.

server. In relayed communication, we Direct via WiFi (between Watch and Server) Direct via WiFi (in the Watch) measured energy consumption in both Relaying via BT Classic (between Phone and Server) Relaying via BT Classic (in the Phone) Relaying via BT Classic (between Watch and Phone) Relaying via BT Classic (in the Watch) Relaying via BLE (between Phone and Server) Relaying via BLE (in the Phone) smartwatch and smartphone, and time 100000 Relaying via BLE (between Watch and Phone) 10000 Relaying via BLE (in the Watch) usage from smartwatch to smartphone and 10000 1000 from smartphone to the third-party server. 1000 Figure 4(a) shows the time taken for all 100 the three methods (note the log-y axis). The Time (ms) 100 total time for the smartwatch to download 10 10 Energy consumption (mJ) the object by relaying via BLE is less for smaller file sizes (1 byte to 10 bytes) as the 1 1 1B smartphone downloads the objects faster 1B 10B 10B 1KB 2KB 5KB 8KB 100B 500B 1KB 2KB 5KB 8KB 100B 500B 10KB 10KB than the smartwatch and BLE also assures the least connection establishment time (a) Time consumption of relayed (b) Energy consumption of relayed compared to BT-Classic [7]. However, since and direct communication. and direct communication. BLE allows for short bursts (20 bytes) and is not designed for continuous connections, FIGURE 4. Cost of direct vs. relayed communication. larger objects are transmitted in smaller chunks [5]. Therefore, completion time increases drastically with object size for Measurement methodology: We only to the smartwatch. Although BLE is not BLE due to the lower effective data rate. use the LG Urbane watch running used in any of the apps considered in Direct Wi-Fi communication took the least Android Wear that runs tcpdump and the previous experiments, it is a natural time (including Wi-Fi association time) Bluetooth HCI Snoop in the device. Energy candidate for relayed communication for for all object sizes larger than 100 bytes. consumption is measured with a Monsoon Method-2. Therefore, we conducted the Relaying via BLE is the most energy- power monitor directly connected via above measurements using both BLE and efficient method in the smartwatch, if the USB. In direct communication, the BT-Classic. We chose HTTPS in direct object size is smaller than 100 bytes as smartwatch app sends HTTPS requests connections, as it is the only protocol shown in Figure 4(b). In contrast, energy directly to a local server via Wi-Fi and used in direct Internet communications consumption for direct communication downloads the requested object. In relayed from wearables. In Android BLE is larger for smaller object sizes in the communication, the smartwatch app sends development, we used BluetoothGatt and smartwatch, due to the costly TLS download requests to the companion BluetoothGattCallback classes in order to handshake phase in HTTPS. However, app on the smartphone via Bluetooth connect to a BLE-enabled device. In direct when the file size increases, BLE becomes and then the smartphone sends HTTPS communication, we measured the energy the worst mode among the three methods, requests to the server, downloads the consumption in the smartwatch and time because the lower data rate in BLE has a requested object and instantly uploads taken from smartwatch to the third-party greater effect than connection establishment

September 2017 | Volume 21, Issue 3 GetMobile 9 [past➔Future]

cost in BT-Classic and TLS handshake data communications involve 1 KB Diego Perino is a researcher at Telefonica phase in HTTPS. Therefore, direct or larger files, we do not recommend Research in Barcelona, Spain. He received Internet communication via Wi-Fi is BLE be used for relayed Internet a PhD in Computer Science from the Paris Diderot-Paris 7 University, and MS from the best method in terms of energy communication from wearables. Politecnico di Torino and Eurecom institute. consumption in the smartwatch for larger • Most current wearable apps leverage the His research focuses on design and file sizes. However, the cumulative energy smartphone for Internet connectivity, performance evaluation of networking consumption in the smartwatch and the regardless of device capability. However, protocols and systems. He has published smartphone is larger in BLE relaying than Bluetooth relaying increases both the several papers at international conferences in direct communication for all the sizes. energy consumption and data transfer and in journals, and also filed several patents. All the considered applications in the time. Therefore, future wearables apps Dwight Makaroff is a professor in the previous section require 1 KB or larger files can be developed to leverage direct Wi-Fi Computer Science Department at the transmission. In this case, Wi-Fi provides connectivity whenever Wi-Fi connectivity University of Saskatchewan, Canada. He the minimal power/throughput ratio, and is is available. To realize this, we recommend obtained his PhD at the University of British thus more power efficient than BT-Classic that app developers utilize basic networking Columbia in 1998 in Multimedia Systems. and BLE relaying. We have shown that the APIs rather than Wearable APIs (e.g., His current research interests are distributed systems performance, including network direct Internet communication is much HttpsURLConnection class rather than protocols, sensor networks, big data more efficient than any other relaying Wearable Data Layer APIs) for Android architecture frameworks, wearable systems, method for object sizes currently used in Wear. n and networked games. wearable apps. Aruna Seneviratne is currently the research director of Cyber-Physical Systems Research Harini Kolamunna is a PhD candidate at CONCLUDING REMARKS Program in Data61-CSIRO and a professor the School of Electrical Engineering and Secure, direct Internet Wi-Fi connectivity at UNSW, Australia. He was the foundation Telecommunications, UNSW Australia, and on wearables is practically feasible. In professor of Telecommunications at UNSW, attached to Data61-CSIRO. She received a fact, the direct Internet communication where he holds the Mahanakorn Chair of bachelor’s degree in Electrical & Electronics Telecommunications. He received his PhD in reduces energy consumption and improves Engineering with a First Class Honours from electrical engineering from the University of performance compared to the current University of Peradeniya, and worked as a Bath, UK. His research interests are in mobile norm of Bluetooth relaying. Therefore, research assistant at National University of technologies, networking and communications, Singapore (2013-14). Her current research we advocate that wearable app/system and computer system security. developers should leverage these advanced interests include wearable/IoT technologies, capabilities of wearables to drive a networking and communications. paradigm shift toward standalone wearable Jagmohan Chauhan is a PhD candidate in devices. In particular, we provide the Electrical Engineering and Telecommunica- REFERENCES following recommendations: tions at UNSW, Australia. Before joining UNSW, he received a MS from University of Saskatch- [1] T. Danova. “The wearables report: Growth trends, consumer attitudes, and why • Relayed communication via smartphone ewan in 2013. His research interests include mobile systems, security and deep learning. smartwatches will dominate,” http://www. is not imperative for functionality of businessinsider.com.au/the-wearable-computing- many apps and, thus, wearable apps can Yining Hu is a PhD candidate at UNSW, market-report-2014-10 , October 2014. directly communicate with the Internet. Australia, affiliated to Data61-CSIRO. She [2] Android.com, “Sending and syncing data”, • The relative cost of enabling secure received a bachelor’s degree in Engineering https://developer.android.com/training/ (Electrical) with First Class Honours from the wearables/data-layer/index.html. direct communication on wearables is University of Sydney, Australia, and Harbin [3] D. Naylor, A. Finamore, I. Leontiadis, comparable to smartphones, despite Institute of Technology, China in 2016 (joint Y. Grunenberger, M. Mellia, M. Munafò, the resource constraints on wearable program). Her current research interests K.Papagiannaki, and P.Steenkiste, “The cost of devices. Thus, standalone secure include data integrity preservation in wearable the “S” in HTTPS”, CoNEXT ’14, Dec. 2014, wearable applications can be practically systems and blockchains. pp. 133-140. [4] J. Rosskind, “Multiplexed transport over UDP,” realized utilizing existing secure Kanchana Thilakarathna is a Lecturer in Google White Paper, 2013. protocols such as HTTPS. Distributed Computing at the School of [5] Bluetooth SIG, “Bluetooth core specification,” • Although TLS overhead is significant Information Technologies, The University of https://www.bluetooth.com/specifications/ for smaller data transfers, keeping the Sydney. Previously, he was a Research Scientist bluetooth-core-specification. at Networks Group, Cyber-Physical Systems [6] H. Kolamunna, J. Chauhan, Y. Hu, K. connection live is only beneficial if the Thilakarathna, D. Perino, D. Makaroff and Research Program at Data61-CSIRO. He interval in between two transfers is less A. Seneviratne, “Are wearable devices ready received his PhD in Electrical Engineering and than 500 ms for modern wearables with for HTTPS? Measuring the cost of secure Telecommunications from UNSW Australia. Wi-Fi connectivity, which is almost a communication protocols on wearable devices,” His research interests include developing continuous stream of data. https://arxiv.org/abs/1608.04180, December 2016. technologies for resource allocation, secure [7] Link Labs, “Bluetooth vs. bluetooth low energy:

• Bluetooth Low Energy (BLE) is not communication and authentication, and What’s the difference?” https://www.link-labs. energy- and time-efficient for transferring privacy-preserving data sharing in wearable/ com/blog/bluetooth-vs-bluetooth-low-energy, 1 KB or larger files. As typical wearable mobile/IoT networks. November 2015.

10 GetMobile September 2017 | Volume 21, Issue 3