I still See You! Inferring Fitness Data from Encrypted Trafﬁc of

Wearables

Andrei Kazlouski

1,2

, Thomas Marchioro

1,2

, Harry Manifavas

1,2

and Evangelos Markatos

1,2

Computer Science Department, University of Crete, Greece

Institute of Computer Science, Foundation for Research and Technology, Greece

Keywords:

Wearables, Security, Privacy.

Abstract:

In this paper we describe a cyberattack against 2 well-known wearable devices. The attacker presented in this

paper is an “honest but curious” Internet Service Provider (ISP) sitting somewhere in the path between the

device and the cloud. The ISP launches the attack when the smartbands try to synchronize their data with the

permanent cloud storage. By launching its attack, this “honest but curious” ISP is able to learn much personal

information about the users of the smartbands, including the frequency of measuring the users’ heart rate and

weight; the number and duration of workouts; as well as whether (i) sleep or (ii) steps were recorded on a

given day. We show that privacy leaks might occur even when the transferred data are fully encrypted, and the

representative mobile application utilizes state-of-the-art security mechanisms: certiﬁcate pinning, and source

code obfuscation.

1 INTRODUCTION

Over the past few years there have been an impres-

sive increase in the uptake and everyday use of wear-

able devices, such as wristbands and smartwatches.

Worn by the end users 24 hours per day - seven days

per week, these devices measure, collect, and com-

municate a wealth of health- and ﬁtness-related infor-

mation. As a result, consumers can ﬁnd out how in-

tensely they exercise and what is their progress over

time. Although this information is collected on the

end device (wristband), it is usually sent to the user’s

smartphone and eventually transferred to the perma-

nent storage space in the cloud associated with the

manufacturer of the wearable device. However, the

information collected by those wearable devices is

personal and may sometimes be deeply conﬁdential.

Indeed, a user’s heart rate, sleep patterns, stress and

oxygen saturation levels can be used to draw impor-

tant conclusions about physical and mental health.

In this paper we explore whether private health

data can be retrieved by undesirable third parties. Al-

This project has received funding from the European

Union’s Horizon 2020 research and innovation programme

under the Marie Skłodowska-Curie grant agreement No

813162. The content of this paper reﬂects the views only

of their author (s). The European Commission/ Research

Executive Agency are not responsible for any use that may

be made of the information it contains.

though there are several places where this informa-

tion can be leaked, including (i) the wristband which

is used by the end user, (ii) the smartphone where the

app runs, or (iii) even the cloud where the data are

stored, in this paper we focus on the communication

link between the smartphone and the cloud.

Threat Model. The threat model that we consider in

this paper is as follows: we assume that the user has a

wearable device. The device is connected to a smart-

phone via Bluetooth and the smartphone is connected

to the cloud via the open Public Internet. We assume

that one of the ISPs who links the user’s smartphone

to the cloud would like to ﬁnd information about her.

Such information may include whether the user owns

a wristband, how often the user trains, what is the du-

ration of the training sessions, etc. This ISP could

be the ﬁrst one that connects the user to the Internet,

or even another ISP down the line in the path from

the user’s smartphone to the cloud. The ISP is as-

sumed to be “honest but curious”, i.e it will not try

to actively attack the user by installing a “man-in-the-

middle” (MITM) proxy or exploiting other vulnera-

bilities. The ISP will honestly just do its job, that is

to deliver the user’s IP packets to their destination.

At the same time, however, the ISP may try to ﬁnd

as much information as possible from the received IP

packets. Figure 1 displays a diagram of the threat

model we consider. To our knowledge, our work is

Kazlouski, A., Marchioro, T., Manifavas, H. and Markatos, E.

I still See You! Inferring Fitness Data from Encrypted Trafﬁc of Wearables.

DOI: 10.5220/0010233103690376

In Proceedings of the 14th International Joint Conference on Biomedical Engineering Systems and Technologies (BIOSTEC 2021) - Volume 5: HEALTHINF, pages 369-376

ISBN: 978-989-758-490-9

369

Figure 1: We assume that the smartband is connected to the smartphone which uploads the data on the cloud over the Internet

- over one or more Internet Service Providers (ISPs). We assume that at least one of the ISPs is honest but curious; it accepts

IP packets to be delivered to the cloud. It does not try to actively attack the user, but rather to infer information from trafﬁc.

the ﬁrst to do a successful passive attack in the do-

main of ﬁtness trackers. We discuss prior attack mod-

els in section 2.

Motivation for the Attack. A valid question to ask

would be: Is it plausible that a major ISP would tar-

nish their reputation, and engage in mass proﬁling?

We argue, however, that it might not be major ISPs

who would be willing to perform the attack. Cor-

porate health and wellness is growing increasingly

popular lately. Lesser companies utilize wearables to

boost the health of their employees

. In case when an

organisation does not force workers to reveal their ﬁt-

ness data, they can still launch constant health surveil-

lance of the employees, acting as a curious ISP. Be-

sides, it is nearly impossible to detect a passive at-

tacker who does not attempt to modify the data.

Contributions. The contributions of this paper can

be summarized as follows:

• We present the architecture of a system that stud-

ies the information sent from the smartbands to

the cloud.

• We demonstrate that it is possible for “honest but

curious” ISPs to ﬁnd information about the users’

patterns and activities even when the communi-

cation between the smartphone and the cloud is

encrypted.

• We show that encryption alone might not enough

to protect user’s privacy. We propose approaches

that when combined with encryption can be used

to preserve privacy in a much more effective way.

2 RELATED WORK

Security of ﬁtness trackers has been widely an ob-

ject of study. Several works have shown that even

the most popular devices do not always apply state-

of-the-art security mechanisms, enabling the attacker

https://www.washingtonpost.com/business/economy/with-

ﬁtness-trackers-in-the-workplace-bosses-can-monitor-

your-every-step–and-possibly-more/2019/02/15/

75ee0848-2a45-11e9-b011-d8500644dc98 story.html

to exploit the lack of protection. Prior works have

performed attacks on smartbands with an active ad-

versary, and evaluated security of wearables.

Trafﬁc Analysis of HTTPS. The idea of encrypted

trafﬁc leaking information has been around since the

introduction of HTTPS. Trafﬁc Analyses of the HTTP

Protocol over TLS were conducted in (Cheng and

Avnur, 1998; Danezis, 2009; Bissias et al., 2005). In

(Chen et al., 2010; Zhang et al., 2010; Sun et al.,

2002) authors presented side-channel leaks in web

services. Hitz was able to ﬁngerprint websites based

on encrypted trafﬁc (Hintz, 2002). Liberatore and

Levine in turn were able to proﬁle users of websites

based on encrypted trafﬁc (Liberatore and Levine,

2006). All these papers prove that encryption alone

is often not enough to prevent possible privacy leaks.

Attacks on Smarbands. A number of previous

works demonstrated successful active attacks on var-

ious wristwatches exploiting different vulnerabilities

(Zhang and Liang, 2017; Rahman et al., 2013). These

papers imply full access for the adversary to the band,

phone, and in some cases active (Fereidooni et al.,

2017a; Fereidooni et al., 2017b) require a MITM

setup for the attack. Thus, their most probable attack

model is a malicious user, not an ISP. In these studies

authors were able to bypass TLS encryption and in-

ject fake data to the remote server. Arias et al. (Arias

et al., 2015) managed to access the internal ﬂash of

Nike+ Fuelband, inject a modiﬁed ﬁrmware, and take

full control on the band.

Security Analysis of Commercial Wristwatches.

Previous works conducted security studies on the par-

ticular consumer samrtbands (Clausing and Schiefer,

2016; Cyr et al., 2014; Goyal et al., 2016; Andrew

et al., 2016; Clausing et al., 2015b; Clausing et al.,

2015a). These works examined security of consumer

wearables, including Fitbit, Jawbone, Xiaomi, Ap-

ple, Microsoft, Mobile Action, etc. These reports

reviewed whether devices use encryption; the source

code of the applications is obfuscated; certiﬁcate pin-

ning is utilized; and secure Bluetooth Low Energy

(BLE) connection is in place.

HEALTHINF 2021 - 14th International Conference on Health Informatics

370

3 ATTACK AND SETTINGS

In this section we describe the attack in details. We

also provide the setting of our experimental infras-

tructure and our employed tools.

3.1 Attack Description

Following our threat model (section 1) the attacker

aims to passively proﬁle users of smartbands based on

the IP trafﬁc he receives. On a high level our attack

consists of three main steps:

1. discovering the ground truth

2. inferring the data leaks from encrypted trafﬁc

3. mass proﬁling end users of smartbands.

First two steps the curious ISP performs on a local

setup as a preparation for the attack. The third step the

attacker launches globally, analyzing all the IP trafﬁc

that it receives and forwards.

Discovering the Ground Truth. By “ground truth”

we imply the actual data that are sent before encryp-

tion. Being able to synchronize a single activity at a

time, the adversary is able to observe the exact en-

crypted trafﬁc that corresponds to a speciﬁc activity.

The attacker aims to ﬁnd patterns in encrypted trafﬁc

that reveal what data are being transffered. To learn

so, the ISP employs a MITM proxy between a smart-

phone which runs a representative app, and the cloud.

Such proxy allows the adversary to observe all the

data in plain text. In short, MITM (i) decrypts the traf-

ﬁc, (ii) examines the packet contents, (iii) re-encrypts

the trafﬁc, and ﬁnally (iv) sends the trafﬁc to its des-

tination. Step (ii) above enables the attacker to look

into the packets and ﬁnd out what exactly is commu-

nicated between the smartphone and the cloud. Steps

(iii) and (iv) are necessary so as to make sure that

communication between the app and the cloud hap-

pens in an un-interrupted way. To clarify, the adver-

sary installs the MITM proxy only on a local testing

setup to study the representative application, it does

not attempt to tamper with users’ phones.

Discovering Data Leaks. After the adversary sees

what data are sent to the cloud after synchronization,

it can compare them with the encrypted IP trafﬁc. At

this step the attacker utilizes speciﬁcs of the TLS en-

cryption: unlike hashing, the size of the output is not

ﬁxed. That is, encryption approximately preserves

size of the input text:

heart rate : 80

encryption

−−−−−→ ABCDEFGHIJKLM

heart rate : 100

encryption

−−−−−→ ABCDEFGHIJKLMN

In this case if the adversary learns that this partic-

ular encrypted text contains heartbeat data, it will be

able to differentiate between 2 and 3-digit beats per

minute (BPM). To learn the ground truth for all pos-

sible activities, the ISP repeats the above process for

every action. That is, it synchronizes 1 activity at a

time, and sends all possible variation of the given ac-

tivity to the cloud. Based on the data obtained from

MITM and the size of the correspondent ciphertext,

it tries to retrieve information about this action. If the

activity produces more than a single encrypted packet,

the adversary has to consider not only the size of the

packets, but also their order.

Mass Proﬁling of End Users. Once the curious ISP

is able to identify activities that are represented by

speciﬁc sequences of encrypted packets, it is ready

to apply this attack on a bigger scale. At this step,

however, the adversary cannot utilize MITM; it can

only rely on the plain IP packets that are arriving to be

transferred further. Here the attacker is able to exploit

the fact that vendors of smartbands do not have many

unique IP addresses assigned to their servers that store

data of users. By patiently talking with manufacturer

servers on its test setup, the adversary is able to grad-

ually learn all the unique IPs of the storage cloud.

While TLS allows parts of the accessed URL to be

encrypted, and, thus, inaccessible for the ISP, there is

no way to conceal IP addresses. To successfully es-

tablish mass proﬁling, the ISP needs to:

• ﬁlter the trafﬁc according to the list of IP ad-

dresses of vendors servers

• apply the metadata rules learned from previous

steps.

3.2 Settings

Studied Fitness Trackers. In this paper we do

not use the real company and product names. We

adopt pseudonyms instead. We studied 2 of the most

popular smartbands readily available: SmartBandA

and SmartBandB . We notiﬁed the affected companies

about the vulnerabilities.

Learning Ground Truth. For our MITM setup, we

utilized the MITM proxy Burp Suite

. To disable cer-

tiﬁcate pinning we employed an open-source Frida

toolkit

. To observe the encrypted trafﬁc, we used the

network protocol analyzer Wireshark

. We run the

latest android apps on a Google Nexus 6 phone.

Mass Surveillance. For trafﬁc ﬁltering we utilized

the intrusion detection system Snort

and Wireshark.

https://portswigger.net/burp

https://frida.re/

https://www.wireshark.org/

https://www.snort.org/

I still See You! Inferring Fitness Data from Encrypted Trafﬁc of Wearables

371

Table 1: Information about the activities of users for 2 studied smartbands that the adversary is able to learn. Occurrence

implies that the attacker can detect whether the activity was done by the user; hence, its frequency as well.

Activity SmartBandA SmartBandB

Heartbeat occurrence occurrence & whether heart rate is ≥ 100 BPM

Weight occurrence occurrence & whether weight is ≥ 100 kg

Workout occurrence & duration of the workout occurrence

Steps - occurrence

Sleep occurrence occurrence

3.3 Automatic Activity Aetection

Following the formal attack description, we designed

a pipeline for the automatic activity detection.

Gathering All Relevant IPs. The attacker collects

a list of IP addresses the smartband talks to. This is

achieved by continuously initiating connection with

the band and collecting correspondent IP addresses.

Trafﬁc Filtering. The adversary ﬁlters trafﬁc by the

collected IP list, using a Network Intrusion Detection

& Prevention System Snort.

Applying Metadata Rules. The ISP applies the pre-

viously learned rules for detecting activities using

TShark: a Python implementation of the network pro-

tocol analyzer Wireshark. TShark enables more func-

tionality for the TLS processing.

Table 1 illustrates what information the ISP is able

to ﬁnd out about 2 studied smartwatches. We explain

our ﬁndings, and data leaks in the next 2 sections.

4 CompanyA SMARTBAND

Following the section 3.1, the adversary aims to re-

trieve information from the encrypted trafﬁc. The of-

ﬁcial mobile application for CompanyA SmartBandA

is called AppA . It is one of the most used apps for

wearable devices. Overall, the application employs

many state-of-the-art security mechanisms including

source code obfuscation, SSL pinning, TLS protocol

to ensure integrity and conﬁdentiality of the personal

data.

4.1 Detected Activities

We have noticed that the different activities produce

different patterns in the trafﬁc generated in the net-

work (as expected). For many activities AppA en-

codes data in the URL-format before sending. We

learned that the same actions are represented by a de-

termined sequence of packets of almost the same size.

Occasionally the same activities can produce packets

of a slightly different size. That occurs due to the

metadata that is sent together with the health infor-

mation. For instance, the URL representation of the

18 : 40 and 6 : 40 clock times would differ by 1 char-

acter. Similarly, the encrypted payload sizes would

differ by 1 byte. For applicable activities, we will in-

troduce the range of ±X bytes that accounts for such

possibilities. In the next sections we describe individ-

ual trafﬁc sequences in more details. Table 2 depicts

the size of the encrypted trafﬁc for transferred data.

To summarize, the attacker is able to detect heart-

beat measuring frequency; exercising frequency, and

workouts length; whether the user slept, and recorded

weight.

Table 2: Size of encrypted activity packets for Smart-

BandA. File(s) illustrates what plain text json ﬁles are sub-

mitted to the cloud. Size is measured in bytes.

Activity File(s) Size of File(s)

Heartbeat

H1 981 + 142 ∗ K ± 1

H2 16450 ± 50

Workout

W1 ≥ 1293

W2 S = 1725 ± 25

Sleep S1 8140 ± 40

Weight We1 1182 ± 3

4.1.1 Heartbeat Detection

Heartbeat can be easily measured by pressing a

correspondent button on the smartband. When the

application synchronizes with the cloud, it sends two

json ﬁles: (i) H1 and (ii) H2. The H1 ﬁle contains (i)

the metadata and (ii) user’s proﬁle settings. The H2

ﬁle contains information exclusively about the heart-

beat rate measured by the wristwatch and sent in the

URL-encoding format. It contains all the heartbeat

measurements that were taken by the user before the

previous synchronization with the application (could

be more than one measurement). A single heartbeat

measurement always produces a H2 json ﬁle that

is 1123 bytes. We have observed that if the user

takes two heartbeat measurements (i.e. pushes the

button twice), the wristband will send a 1123 + 142

bytes ﬁle. Similarly, if the user takes three heartbeat

measurements, the wristband will send a ﬁle that

is 1123 + 2 × 142 bytes. It appears that for each

extra measurement, the appended value is always

142 bytes. For instance, an additional heartbeat

of 69 BPM would add the following string to the

HEALTHINF 2021 - 14th International Conference on Health Informatics

372

json ﬁle: ,{"time":1591966729,"rate":"RQ==",

"type":2,"device id":"16-digit-ID","source

":25}. Since the BPM is represented by 4 characters

(RQ==), the size of an extra measurement always

stays constant. We veriﬁed that the URL-encoding of

this sequence produces a string of bytes that is 142

bytes long exactly.

We took as many as 50 measurements before syn-

chronizing, and found that the every single experi-

ment ﬁt the following formula: S = 981+142×K ±1.

4.1.2 Workout Duration Detection

The CompanyA wristwatch offers a great variety of

exercising types: running, walking, cycling, swim-

ming, etc. Users can start a new workout by sim-

ply pressing the correspondent button on their smart-

watches. We established that a workout activity pro-

duces two json ﬁles: (i) W1 and (ii) W2. W2 con-

tains statistical information about the workout such

as a maximal reached speed, average stride length,

minimal and maximal heart rate, number of burned

calories. The structure of this ﬁle appears to stay rela-

tively predictable regardless of the workout type, du-

ration, and intensity. Indeed, the size of this ﬁle is

always S = 1725 ± 25 bytes. The W1 ﬁle contains

the “trace” of the user’s heartbeat during the work-

out. This trace shows every change of the heart-

beat. For example 79;3, −1,2. This “toy” trace ac-

counts for user’s heart rate starting at 79, following

by 79 + 3 = 82, dropping to 82 − 1 = 81, and ﬁ-

nally settling at 81 + 2 = 83. Since ﬁle W1 contains

the entire trace of a user’s heartbeat, it appears that

the length of W1 is correlated with the duration of

the workout. To verify this assumption we manu-

ally collected a dataset consisting of seventeen work-

outs, and tried to ﬁt the linear curve through the dat-

apoints. Figure 2 suggests that the empirical data ﬁt

the payload = 1134 + 2.9 ∗ time formula. To roughly

estimate the duration of a workout, the following for-

mula can be applied T = (S − 1134)/2.9, where S is

the size of the packet carrying workout data.

Unlike the heartbeat activity, workouts do not pile

in a single json ﬁle, but are sent as independent pairs

of W1 and W2. To detect the workout activity, adja-

cent packets that satisfy above size requirements need

to be detected. Similarly to heartbeat, the workout

activity is represented by multiple consecutive pack-

ets, which drastically reduces probability of false pos-

itives. As a result a curious ISP is able to detect the

number of workouts performed by the user since the

last synchronisation. Moreover, it is also possible to

approximately detect the length of the workouts.

Figure 2: Size of “workout trafﬁc” depending on dura-

tion. SmartBandA band does not record workouts under

1 minute. Also once the workout exceeds around 100 min-

utes, it is split into multiple packets, which makes it signiﬁ-

cantly harder to detect. Such split occurs because the maxi-

mal payload size of a TLS packets is 16 KB, and, generally,

after 100 minutes a heartbeat trace exceeds this amount.

4.1.3 Sleep Tracking

Tracking sleep is another feature supported by the

band, which appeals to many users. The band makes

use of the heart rate sensor to detect sleep automati-

cally. For this wristband, the sleeping activity is com-

municated via the S1 ﬁle. This ﬁle also includes (i)

device info: ﬁrmware version, hardware version, bat-

tery level, and (ii) events description: exercise count,

number of alarms received. File S1 appears to be

transferred only after a user has slept. The packets

sent with this ﬁle seem to be (after reconstruction)

8180 ± 2 bytes long. Sleep synchronization differs

from other activities, since it does not produce any

separate ﬁles dedicated to sleep exclusively.

4.1.4 Weight Tracking

Users can input and later adjust their weight in the

AppA application. People who change their weight

frequently are likely caring about their weight, and

consider that information sensitive. Recording weight

always produces the We1. json (denoted as We1)

packet that is always 1182 ± 2 bytes long. Similarly

to sleep detection, changing weight produces only a

single packet per activity, which makes probability of

false positives higher.

5 CompanyB SMARTBAND

This section describes the results obtained for Com-

panyB SmartBandB . The ofﬁcial mobile application

for CompanyB SmartBandB is called AppB. It is a

very popular application for wearables that trends in

I still See You! Inferring Fitness Data from Encrypted Trafﬁc of Wearables

373

Play Market. The app encrypts data, using TLS. Un-

like SmartBandA , SmartBandB is more of a “smart-

watch” than a “ﬁtness tracker” in a traditional sense.

It has the same sensors (heart rate monitor, etc.), but

allows users to input more of their ﬁtness and health

data. The band also uses regular Bluetooth instead

of BLE. Similarly to section 4, we focus on detect-

ing heartbeat, sleep, number of steps, workouts and

weight changes.

5.1 Synchronization of Packets

Unlike AppA, AppB synchronizes all the data at

once. In total 113 unique ﬁles that represent activi-

ties in the JSON format are sent to the server during

synchronization. However, some of these ﬁles can be

mapped to a single bigger activity. For instance, a to-

tal of 9 separate ﬁles (total protein, etc.) are related

to the food (e.g. a burger) that users input into the

application. On the other hand, there is only a single

heart rate ﬁle for the heartbeat activity.

We discovered that for each of the ﬁles the app

checks whether the value has changed (user did a cor-

respondent action); if it is the case, it will send two

ﬁles: (i) /set, and (ii) /changes. If the value has not

changed, the app will only send a (i) /changes ﬁle.

Hence, it is the /set ﬁles that contain the actual data

which the adversary would like to obtain. If a user

does every single activity possible before synchroniz-

ing, the app would send 2 ∗ 113 = 226 ﬁles at ones.

If a user does nothing before synchronization, the

app would send 113 ﬁles, all with the /changes af-

ﬁx. Therefore, if an ISP observes a 119-ﬁles synchro-

nization, it can conclude that user’s actions led to the

change of 6 ﬁles (113 /changes and 6 /set). Each ﬁle is

carried by a single TLS data packet. All 113 /changes

packets can be easily detected. Their POST requests

contain default ﬁelds (URL, User-Agent, Content-

Type, etc.) without any content. This translates into

their encrypted payload being between 580 and 620

bytes long (depending on the URL length). Hence,

packets that exceed this size are /set packets that ac-

tually carry the personal data of users. Following sec-

tion 4, the ISP aims to ﬁnd patterns in encrypted /set

packets to detect various activities.

Order of Synchronized Files. By studying the

source code and observing MITM data, we were able

to split 113 /changes ﬁles in two “buckets”. The ﬁrst

bucket consists of 10 ﬁles that are always sent be-

fore others. The remaining 103 json ﬁles represent

the second bucket; they are sorted alphabetically be-

fore being sent. Files in the ﬁrst bucket, however,

are not sorted. Unfortunately for the attacker, the app

does not always retain the same order when sending

the ﬁles. It occasionally slightly (by 1-5 positions)

changes the arrangement of records. Since the at-

tacker does not have access to the plain text data, he

cannot deterministically infer that the ﬁle #42 repre-

sents heartbeat. Instead the adversary has to consider

the interval between #41-#46; any ﬁle in this range

could potentially correspond to heart rate.

5.2 Detected Activities

For the attacker to successfully detect an activity two

conditions need to be satisﬁed:

• the packet’s TLS payload needs to be of a length

correspondent to a particular activity (e.g. for

heartbeat it is 1077 bytes).

• the packet needs to be within a sending order in-

terval for this activity (e.g. for heartbeat it is be-

tween #41 and #46 out of 113 json ﬁles).

Table 3 depicts studied activities and correspon-

dent encrypted patterns. To summarize, the attacker

is able to detect heart rate measuring frequency, and

heartbeats that are above 100 BPM; workout fre-

quency; whether the user slept, took steps or recorded

weight.

Table 3: Size of encrypted activity packets for Smart-

BandB. The ﬁeld Files shows what plain text json ﬁles

are submitted to the cloud. Interval describes possible or-

der of the packets during synchronization. Size is mea-

sured in bytes. For the BPM (heartbeat) activity the pre-

cise formula for the possible size of the H ﬁle is size =

751 + (326 +

) · K ±

Activity Files Interval Size of File(s)

BPM H 42-47 751 + (326 +

) · K

Workout

W 1-10 ≥ 1720

C 72-73 > 700

Sleep S 111-113 998 or 1002

Steps

St 1-10 ≥ 1216

St2 1-10 > 700

T 1-10 > 700

C 72-73 > 700

A 61-65 > 700

Weight We 60-61 901 or 902

5.2.1 Heartbeat Detection

Heart rate can be measured by navigating to a repre-

sentative section and pressing a button on the band.

Heartbeat is sent to the server via the heart rate/set

(denoted as H) ﬁle. Alphabetically the H ﬁle appears

in positions 42-47. We noticed that a single heartbeat

measurement always results in a H ﬁle that is 1077-

1078 bytes. The 1 byte difference occurs because

HEALTHINF 2021 - 14th International Conference on Health Informatics

374

user’s heart rate can be either a 2- or a 3-digit number.

Similarly to SmartBandA , multiple measurements of

heartbeat are sent in a single ﬁle. If a user takes 2 heart

rate measurements before synchronizing the app; the

size of H increases by 326-327 up to 1404 ± 1 bytes.

A similar length increase is observed for three, and

more heartbeat measurements. We veriﬁed that for an

arbitrary K heartbeat measurements, the size of the H

ﬁle lies within the [751 +326 ×K,751+326×K +K]

bytes interval. Again, the interval is present due to up

to K measurements possibly being 3-digit heart rates.

Hence, the adversary is able not only detect the num-

ber of measurements, but also to tell the exact number

of heartbeat measurements that are > 100 BPM.

5.2.2 Workout Detection

SmartBandB allows users to choose between 17 dif-

ferent workout types: running, walking. cycling, hik-

ing, etc. Workouts are sent to the server as part of an

exercise/set (W) json ﬁle. W is a part of the ﬁrst non-

alphabetic bucket, and can take positions 1-10. Work-

ing out also affects the calories burned json ﬁle (C):

positions 72-73. W contains workout description to-

gether with “workout live data”: the trace of heartbeat

during the exercise. The detection technique from

section 4.1.2 could not be applied because multiple

workouts are sent together in W. The increase of the

ﬁle can be attributed to either a long workout or mul-

tiple exercises. Given only an encrypted ﬁle, it is im-

possible to distinguish between them. Nevertheless,

the attacker can still estimate the minimal size of this

ﬁle. The json will be the shortest in case of a single

workout that lasted 1 second. The shortest value that

we managed to obtain is 1720 bytes. There is no up-

per limit on the size of W (except 16 KB TLS limit).

5.2.3 Sleep Detection

Sleep is automatically recorded by SmartBandB .

Users also have an option of manually edit-

ing/inputting it, and providing a quality mark. Sleep

is transmitted via sleep/set (S) ﬁle that occupies po-

sitions 111-113. A sleep ﬁle is equal to either 998 or

1002 bytes, depending on how the user rated her sleep

on the scale from 1 to 5. Detecting sleep appears to be

relatively easy for the adversary since the encrypted

payload can only be of 2 possible sizes. Hence, an

honest but curious ISP is able to tell if a user slept

since the preceding synchronization.

5.2.4 Retrieving Number of Steps

The SmartBandB band automatically tracks number

of steps taken by users. This information is recorded

in the step count/set (denoted as St) ﬁle that takes po-

sitions 1-10. Taking steps also causes four other ﬁles

to be transmitted to the server: step daily trend (#1-

10), tracker.pedometer day summary (#1-10), calo-

ries burned (#72-73), activity.day summary (#61-

65). St describes all the steps that were taken since

the previous synchronization. It displays them as in-

tervals depending on speed. For example if a user

took 100 steps at a normal pace, and then run another

100 steps, the data will be recorded as two separate

intervals. This means that similarly to section 5.2.2,

there is no upper limit on the size of the St ﬁle (ex-

cept 16 KB). We tried to establish the minimal size of

the ﬁle by taking a single step before synchronizing.

In this case St is 1216 bytes long. Considering that

taking steps invokes changes of 4 different ﬁles, the

attacker is able to detect the activity with a very high

probability.

5.2.5 Weight Detection

Users can record their weight in the AppB app.

Weight is send to the cloud via weight/set (denoted

as We): positions 60-61. This ﬁle can be either 901 or

902 bytes long depending on whether the input weight

is a 2- or a 3-digit number (in kg). Interestingly this

allows the attacker to proﬁle users whose weight ex-

ceeds 100 kilograms.

6 DISCUSSION

TLS and Wearables. Side-channel leaks of the TLS

encryption have been discovered in many web-related

systems. Most of such attacks, however, were only

able to reduce entropy about the encrypted data. In

our setup the attacker is able to extract relevant con-

clusions about the activities performed by users. Un-

like the TLS leaks for web services, the ISP can send

a single activity at a time, and directly pinpoint en-

crypted packets that correspond to a particular activ-

ity. This enables the adversary to infer data leaks with

greater precision.

Possible Countermeasures:

• Modifying Plain → Cipher Text Size Ratio. Modi-

ﬁcation of encrypted payload size can be achieved

by modifying the plain text json ﬁles. Since prun-

ing those ﬁle may result in data corruption, the

natural solution would be to selectively increase

some of the transmitted ﬁles. This can be achieved

with “dummy” text to extend ﬁles to an arbitrarily

sized threshold.

• Concealing Frequency of Packets Transmission.

To complicate the process of matching pairs of

I still See You! Inferring Fitness Data from Encrypted Trafﬁc of Wearables

375

plain text with encrypted trafﬁc, the app might de-

lay sending user data to the server.

• Introducing Randomness for Order of Packets.

The process of mapping an activity to its en-

crypted counterpart could be convoluted by send-

ing activities to a server in a random order.

Randomizing the transmitting sequence makes it

harder for the adversary to establish patterns in

encrypted trafﬁc.

We leave development of a secure trafﬁc transmis-

sion system for future work.

7 CONCLUSION

With a vast number of different commercial smart-

bands readily available, we predict many more wear-

ables leak data while sending them to vendor’s

servers. An “honest but curious” ISP can easily pur-

chase well-known brands of smartbands, and with the

help of the proposed architecture for trafﬁc analysis

identify whether a particular band leaks any user’s

sensitive data. Unlike other attacks on wearables, in

our threat model the adversary only observes the traf-

ﬁc without any intent to modify it. This makes it

extremely laborious to discover the attacker. Even

if detected, it is almost impossible to prove that an

ISP committed an unlawful deed. We show that even

when the connection channel is encrypted, and the

mobile application is reinforced with state-of-the-art

security mechanism, it might still be possible to ob-

tain sensitive information about users. Such data in-

clude frequency of measuring heartbeat and weigh,

the number and duration of workouts, occurrence of

sleep, steps, and food records. Naturally, we do not

discourage usage of modern defense techniques, but

rather challenge vendors to consider bolstering their

security even further. Finally, we propose several

methods for the attack’s mitigation.

REFERENCES

Andrew, H., Christopher, P., and Jeffrey, K. (2016). Ev-

ery step you fake: A comparative analysis of ﬁtness

tracker privacy and security. Open Effect Report.

Arias, O., Wurm, J., Hoang, K., and Jin, Y. (2015). Pri-

vacy and security in internet of things and wearable

devices. IEEE Transactions on Multi-Scale Comput-

ing Systems, 1(2):99–109.

Bissias, G. D., Liberatore, M., Jensen, D., and Levine,

B. N. (2005). Privacy vulnerabilities in encrypted http

streams. In International Workshop on Privacy En-

hancing Technologies, pages 1–11. Springer.

Chen, S., Wang, R., Wang, X., and Zhang, K. (2010). Side-

channel leaks in web applications: A reality today, a

challenge tomorrow. In 2010 IEEE Symposium on Se-

curity and Privacy, pages 191–206. IEEE.

Cheng, H. and Avnur, R. (1998). Trafﬁc analysis of

ssl encrypted web browsing. URL citeseer. ist. psu.

edu/656522. html.

Clausing, D.-I. E., Schiefer, M., L

osche, U., and Morgen-

stern, D.-I. M. (2015a). Security evaluation of nine

ﬁtness trackers. The Independent IT-Security Institute.

Clausing, E. and Schiefer, M. (2016). Internet of things: Se-

curity evaluation of 7 ﬁtness trackers on android and

the apple watch. AV TEST, Germany.

Clausing, E., Schiefer, M., and Morgenstern, M. (2015b).

Internet of things: security evaluation of nine ﬁtness

trackers. AV TEST, The Independent IT-Security in-

stitue, Magdeburg, Germany.

Cyr, B., Horn, W., Miao, D., and Specter, M. (2014). Secu-

rity analysis of wearable ﬁtness devices (ﬁtbit). Mas-

sachusetts Institute of Technology, 1.

Danezis, G. (2009). Trafﬁc analysis of the http protocol

over tls.

Fereidooni, H., Classen, J., Spink, T., Patras, P., Mietti-

nen, M., Sadeghi, A.-R., Hollick, M., and Conti, M.

(2017a). Breaking ﬁtness records without moving:

Reverse engineering and spooﬁng ﬁtbit. In Interna-

tional Symposium on Research in Attacks, Intrusions,

and Defenses, pages 48–69. Springer.

Fereidooni, H., Frassetto, T., Miettinen, M., Sadeghi, A.-

R., and Conti, M. (2017b). Fitness trackers: ﬁt for

health but unﬁt for security and privacy. In 2017

IEEE/ACM International Conference on Connected

Health: Applications, Systems and Engineering Tech-

nologies (CHASE), pages 19–24. IEEE.

Goyal, R., Dragoni, N., and Spognardi, A. (2016). Mind

the tracker you wear: a security analysis of wearable

health trackers. In Proceedings of the 31st Annual

ACM Symposium on Applied Computing, pages 131–

136.

Hintz, A. (2002). Fingerprinting websites using trafﬁc anal-

ysis. In International workshop on privacy enhancing

technologies, pages 171–178. Springer.

Liberatore, M. and Levine, B. N. (2006). Inferring the

source of encrypted http connections. In Proceedings

of the 13th ACM conference on Computer and com-

munications security, pages 255–263.

Rahman, M., Carbunar, B., and Banik, M. (2013). Fit and

vulnerable: Attacks and defenses for a health moni-

toring device. arXiv preprint arXiv:1304.5672.

Sun, Q., Simon, D. R., Wang, Y.-M., Russell, W., Padman-

abhan, V. N., and Qiu, L. (2002). Statistical identiﬁ-

cation of encrypted web browsing trafﬁc. In Proceed-

ings 2002 IEEE Symposium on Security and Privacy,

pages 19–30. IEEE.

Zhang, K., Li, Z., Wang, R., Wang, X., and Chen, S. (2010).

Sidebuster: automated detection and quantiﬁcation of

side-channel leaks in web application development.

In Proceedings of the 17th ACM conference on Com-

puter and communications security, pages 595–606.

Zhang, Q. and Liang, Z. (2017). Security analysis of blue-

tooth low energy based smart wristbands. In 2017

2nd International Conference on Frontiers of Sensors

Technologies (ICFST), pages 421–425. IEEE.

HEALTHINF 2021 - 14th International Conference on Health Informatics

376