Secure Management of Low Power Fitness Trackers

TL;DR

This paper identifies security vulnerabilities in popular fitness trackers, introduces tools to exploit these vulnerabilities, and proposes a lightweight, secure protocol and platform to enhance data security and reduce synchronization overhead.

Contribution

It presents novel attack tools for fitness trackers, a new secure protocol SensCrypt, and an affordable Arduino-based tracker platform to improve security and efficiency.

Findings

Vulnerabilities found in Fitbit Ultra and Garmin Forerunner 610

SensCrypt effectively secures data against identified attacks

Sens.io reduces synchronization overhead significantly

Abstract

The increasing popular interest in personal telemetry, also called the Quantified Self or "lifelogging", has induced a popularity surge for wearable personal fitness trackers. Fitness trackers automatically collect sensor data about the user throughout the day, and integrate it into social network accounts. Solution providers have to strike a balance between many constraints, leading to a design process that often puts security in the back seat. Case in point, we reverse engineered and identified security vulnerabilities in Fitbit Ultra and Gammon Forerunner 610, two popular and representative fitness tracker products. We introduce FitBite and GarMax, tools to launch efficient attacks against Fitbit and Garmin. We devise SensCrypt, a protocol for secure data storage and communication, for use by makers of affordable and lightweight personal trackers. SensCrypt thwarts not only the attacks we introduced, but also defends against powerful JTAG Read attacks. We have built Sens.io, an Arduino Uno based tracker platform, of similar capabilities but at a fraction of the cost of current solutions. On Sens.io, SensCrypt imposes a negligible write overhead and significantly reduces the end-to-end sync overhead of Fitbit and Garmin.

Tables

Table 1. TABLE I: Types of data harvested by FitBite and GarMax from Fitbit and Garmin. Garmin provides GPS tagged fitness information, which GarMax is able to collect.

Type of data	FitBite	GarMax
Device info	✓	✓
User profile, schedules, goals	✓	✓
Fitness data	✓	✓
(GPS) Location history	✗	✓

Table 2. TABLE II: Symbol definitions.

Notation	Definition
$U$, $T$, $B$, $W$	user, tracker, base and webserver
$i{d}_U$, $i{d}_T$, $i{d}_B$	unique identifiers of $U$, $T$ and $B$
dirty	pointer to first written record
clean	pointer to first available record
start, end	pointers to memory bounds
$K_W$	symmetric key maintained by $W$ for $T$
$K_T$	symmetric key shared by $W$ and $T$
$ctr$	counter shared by $W$ and $T$
$Map$	data base of $W$ for users and trackers
$mem$	memory of a tracker

Table 3. TABLE III: Comparison of defenses provided by SensCrypt and FitCrypt against the types of attacks described in Section  III-C when the adversary has a combination of the capabilities described in Section  II-B . Each element in the table describes which attacks are thwarted by the corresponding solution.

Capabilities	SensCrypt	FitCrypt
Inspect	TPDC, TI, UAI	TPDC, TI, UAI
Inject	TPDC, TI, UAI	TPDC, TI, UAI
Capture	TPDC, TI, UAI	TPDC, TI, UAI
JTAG-R	TPDC, TI, UAI	TPDC, TI, UAI
JTAG-RW	TPDC	TPDC
JTAG-R + Inspect	TI, UAI	TPDC, TI, UAI
JTAG-R + Inject	TI	TPDC, TI
Double JTAG-R	TI, UAI	TPDC, TI, UAI

Table 4. TABLE IV: SensCrypt applicability: fitness trackers, home monitoring solutions.

Platform	Type of data	Communication	Coverage	Memory
Fitbit [3]	user profile, fitness, sleep data	ANT+, BT	5-50m	96 KB RAM, 112 KB flash
Garmin FR610 [4]	fitness data, heart rate, location	ANT+	10-20m	1 MB
Nike+ [19]	profile, fitness data	BT	50m	Flash 256KB, RAM 32 KB
Jawbone Up [5]	fitness, sleep data	BT	50m	128KB Flash, 8KB RAM
Motorola MotoActv [14]	fitness data, user profile	ANT+, BT, Wi-Fi	35m	16 GB
Basis B1 [15]	fitness, sleep data, heart rate	BT	50m	7 days of data
Mother [18]	motion, fitness, proximity	915-MHz	30m	32 KB RAM
Nest [16]	utility data	Wi-Fi	35m	512Mb DRAM, 2 Gb flash
Belkin WeMo [17]	home electronics	Wi-Fi	35m	RAM 32 MB, Flash 16 MB

Table 5. TABLE V: RecordData: computation overhead in ms. FitCrypt-RSA 2048 bit is not viable on Arduino (2.3s). FitCrypt-ECC 224 bit (equivalent of RSA 2048 bit) is even less efficient. SensCrypt is 2-3 orders of magnitude more efficient.

Platform	SensCrypt	FitCr-RSA	FitCr-ECC
Fitbit	6.02	2300	2520
Garmin	6.06	2300	2520

Table 6. TABLE VI: Upload: comparison of tracker, webserver and communication delays (shown in ms) of SensCrypt and FitCrypt. FitCrypt (RSA or ECC) is shown both for the Fitbit (96KB) and Garmin (1MB) memory size. The delay of SensCrypt is independent of m ​ e ​ m 𝑚 𝑒 𝑚 mem size, and significantly shorter.

Solutions	T	W	Comm
SensCrypt	502.13	190.4	153
FitCrypt (Fitbit)	904.56	177.36	162
FitCrypt (Garmin)	9366	322	1686

Equations

$$mem[\text{clean}]=D\oplus E_{K_T}(ctr,\text{clean})\oplus E_{K_W}(ctr,clean).$$

$$\mathtt{T}\to \mathtt{B}\to \mathtt{W}:\mathtt{TRQ}-\mathtt{DATA},\mathtt{i}{\mathtt{d}}_{\mathtt{T}},\mathtt{mem}[dirty..clean],$$

$$\mathtt{W}\to \mathtt{B}\to \mathtt{T}:\mathtt{WRITE},\mathtt{i}{\mathtt{d}}_{\mathtt{T}},{\mathtt{E}}_{{\mathtt{K}}_{\mathtt{T}}}(\mathtt{ctr}+1,{\mathtt{E}}_{{\mathtt{K}}_{\mathtt{W}}}(\mathtt{ctr}+1,\mathtt{i})),$$

Full text

We devise SensCrypt, a protocol for secure data storage and communication, for use by makers of affordable and lightweight personal trackers. SensCrypt thwarts not only the attacks we introduced, but also defends against powerful JTAG Read attacks. We have built Sens.io, an Arduino Uno based tracker platform, of similar capabilities but at a fraction of the cost of current solutions. On Sens.io, SensCrypt imposes a negligible write overhead and significantly reduces the end-to-end sync overhead of Fitbit and Garmin.

I Introduction

Wearable personal trackers that collect sensor data about the wearer, have long been used for patient monitoring in health care. Holter Monitors [1], with large and heavy enclosures, that use tapes for recording, have recently evolved into affordable personal fitness trackers (e.g., [2]). Recently, popular health centric social sensor networks have emerged. Products like Fitbit [3], Garmin Forerunner[4] and Jawbone Up [5] require users to carry wireless trackers that continuously record a wide range of fitness and health parameters (e.g., steps count, heart rate, sleep conditions), tagged with temporal and spatial coordinates. Trackers report recorded data to a providing server, through a specialized wireless base, that connects to the user’s personal computer (see Figures 1 and 1). The services that support these trackers enable users to analyze their fitness trends with maps and charts, and share them with friends in their social networks.

All happening too quickly both for vendors and users alike, this data-centric lifestyle, popularly referred to as the Quantified Self or “lifelogging” is now producing massive amounts of intimate personal data. For instance, BodyMedia [6] has created one of the world’s largest libraries of raw and real-world human sensor data, with 500 trillion data points [7]. This data is becoming the source of privacy and security concerns: information about locations and times of user fitness activities can be used to infer surprising information, including the times when the user is not at home [8], and company organizational profiles [9].

We demonstrate vulnerabilities in the storage and transmission of personal fitness data in popular trackers from Fitbit [3] and Garmin [4]. Vulnerabilities have been identified for similar systems, including pacemakers (e.g., Halperin et al. [10]) and glucose monitoring and insulin delivery systems (e.g., Li et. al. [11]). The differences in the system architecture and communication model of social sensor networks enable us to identify and exploit different vulnerabilities.

We have built two attack tools, FitBite and GarMax, and show how they inspect and inject data into nearby Fitbit Ultra and Garmin Forerunner trackers. The attacks are fast, thus practical even during brief encounters. We believe that, the vulnerabilities that we identified in the security of Fitbit and Garmin are due to the many constraints faced by solution providers, including time to release, cost of hardware, battery life, features, mobility, usability, and utility to end user. Unfortunately, such a constrained design process often puts security in the back seat.

To help address these constraints, in this paper we introduce SensCrypt, a protocol for secure fitness data storage and transmission on lightweight personal trackers. We leverage the unique system model of social sensor networks to encode data stored on trackers using two pseudo-random values, one generated on the tracker and one on the providing server. This enables SensCrypt, unlike previous work [10, 12], to protect not only against inspect and inject attacks, but also against attackers that physically capture and read the memory of trackers. SensCrypt’s hardware and computation requirements are minimal, just enough to perform low-cost symmetric key encryption and cryptographic hashes. SensCrypt does not impose storage overhead on trackers and ensures an even wear of the tracker storage, extending the life of flash memories with limited program/erase cycles.

SensCrypt is related to Dabinder (Naveed et al. [13]), an Android level defense. Dabinder generates and enforces secure bonding policies between a device and its official app, to prevent external device mis-bonding attacks for Bluetooth enabled Android health/medical devices. SensCrypt is built for a different platform and also, unlike Dabinder, minimizes the role played by the base.

SensCrypt is applicable to a range of sensor based platforms, that includes a large number of popular fitness [3, 4, 5, 14, 15] and home monitoring solutions [16, 17, 18], as well as scenarios where the sensors need to be immobile and operable without network connectivity (e.g., infrastructure, traffic, building and campus monitoring solutions). In the latter case, the bases through which the sensors sync with the webserver are mobile, e.g., smartphones of workers, who may become proximal to the sensors with the intention of data collection or as a byproduct of routine operations.

We have developed Sens.io, a $52 tracker platform built on Arduino Uno, of similar capabilities with current solutions. On Sens.io, SensCrypt (i) imposes a 6ms overhead on tracker writes, (ii) reduces the end-to-end overhead of data uploads to 50% of that of Fitbit, and (iii) enables a server to support large volumes of tracker communications. In conclusion, the contributions of this paper are the following:

• •

Reverse engineer the semantics of the Fitbit Ultra and Garmin Forerunner communication protocol. [Section II-C].

• •

Build FitBite and GarMax, tools that exploit vulnerabilities in the design of Fitbit and Garmin to implement several attacks in a timely manner [Section III].

• •

Devise SensCrypt, a secure solution that imposes no storage overhead on trackers and requires only computationally cheap operations. [Section IV] Show that SensCrypt protects even against invasive attackers, capable of reading the memory of captured trackers [Section V].

• •

Implement Sens.io, a tracker platform, of similar capabilities with existing popular solutions but at a fraction of the cost [Section VII]. Show that SensCrypt running on Sens.io is very efficient [Section VIII]

While SensCrypt’s defenses may not be immediately adopted by existing products 111We have contacted Fitbit and Garmin with our results. While interested in the security of their users, they have declined collaboration., this paper provides a foundation upon which to create, implement and test new defensive mechanisms for future tracker designs.

II System Model, Attacker and Background

II-A System Model

We consider a general system consisting of tracker devices, base stations and an online social network. We exemplify the model components using Fitbit Ultra [3] and Garmin Forerunner [4], two popular health centric social sensor networks (see Figures 1 and 1). For simplicity, we will use “Fitbit” to refer the Fitbit Ultra and “Garmin” to denote the Garmin Forerunner 610 solution.

The tracker. The tracker is a wearable device that records, stores and reports a variety of user fitness related metrics. We focus on the following trackers:

• •

The Fitbit tracker measures the daily steps taken, distance traveled, floors climbed, calories burned, the duration and intensity of the user exercise, and sleep patterns. It consists of four IC chips, (i) a MMA7341L 3-axis MEMS accelerometer, (ii) a MEMS altimeter to count the number of floors climbed and (iii) a MSP 430F2618 low power TI MCU consisting of 92 KB of flash and 96 KB of RAM. The user can switch between displaying different real-time fitness information on the tracker, using a dedicated hardware switch button (see the arrow pointing to the switch in Figure 1).

• •

The Garmin tracker records data at user set periodic intervals (1-9 seconds). The data includes a timestamp, exercise type, average speed, distance traveled, altitude, start and end position, heart rate and calories burned during the past interval. The tracker has a heart rate monitor (optional) and a 12 channel GPS receiver with a built-in SiRFstarIII antenna. that enables the user to tag activities with spatial coordinates.

Both Fitbit and Garmin trackers have chips supporting the ANT protocol, with a 15ft transmission range for Fitbit and 33ft for Garmin. Each tracker has a unique id, called the tracker public id (TPI). Trackers also store profile information of their users, including age, gender and physiological information such as height, weight and gait information.

The base and agent module. The base connects with the user’s main computing center (e.g., PC, laptop) and with trackers within transmission range (15ft for Fitbit and 33ft for Forerunner) over the ANT protocol. The user needs to install an “agent module”, a software provided by the service provider (Fitbit, Garmin) to run on the base. The agent and base act as a bridge between the tracker and the online social network. They upload information stored on the tracker to its user account on the webserver, see Figures 1 and 1 for system snapshots.

Tracker to base pairing. Fitbit trackers communicate to any base in their vicinity. However, tracker solutions like Garmin Forerunners allow trackers to communicate only through bases to which they have been previously “paired” or “bonded”. Garmin’s pairing procedure works in the following manner. The agent running on the base searches for available ANT enable devices. Each tracker periodically sends broadcast beacons over the ANT interface. If the agent discovers a tracker, it extracts its unique id (TPI). The agent uses one of two methods of authentication: initial pairing or passkey. The agent verifies if it already stores an authfile for this TPI. If no such file exists (i.e., this is the first time the tracker is pairing with the base), the agent uses the pairing method and sends a bind request to the tracker. When prompted, the user needs to authenticate the operation, through the push of a button on the tracker. The agent then retrieves a factory embedded “passkey” from the tracker. It then stores the pair $\langle TPI,passkey\rangle$ in a newly created authfile. During subsequent authentications, the agent uses the passkey method: it recovers the passkey corresponding to the TPI from the authfile and uses it to authenticate the tracker.

The system model considered can be extended to cover the case of fitness tracking solutions that turn the user’s mobile device into a base, e.g., [5, 19, 15]. In such systems, the agent module is a mobile app running on the mobile device. The tracker communicates with the smartphone over existing network interfaces, e.g., Bluetooth or NFC. We note that Naveed et al. [13] identified an intriguing vulnerability of Android smartphones bonded to health trackers. The vulnerability stems from the fact that the bonding occurs at smartphone device level not at the app level. This effectively leaves the health data vulnerable to rogue apps with Bluetooth permissions.

The webserver. The online social network webserver (e.g., fitbit.com, connect.garmin.com), allows users to create accounts from which they befriend and maintain contact with other users. Upon purchase of a tracker and base, the user binds the tracker to her social network account. Each social network account has a unique id, called the user public id (UPI). When the base detects and sets up a connection with a nearby tracker, it automatically collects and reports tracker stored information (step count, distance, calories, sleep patterns) with temporal and spatial tags, to the corresponding user’s social network account. In the following, we use the term webserver to denote the computing resources of the online social network.

Tracker-to-base communication: the ANT protocol. Trackers communicate to bases over ANT, a 2.4 GHz bidirectional wireless Personal Area Network (PAN) ultra-low power consumption communication technology, optimized for transferring low-data rate, low-latency data.

Data conversion. The Fitbit tracker relies on the user’s walk and run stride length values to convert the step count into the distance covered. It then extrapolates the user’s Basal Metabolic Rate (BMR) [20] values and uses them to convert the user’s daily activities into burned calories values. The Garmin tracker uses the GPS receiver to compute the outdoor distance covered by the user. It then relies on the Firstbeat[21] algorithm to convert user data (gender, height, weight, fitness class) and the captured heart rate information to estimate the user’s Metabolic Equivalent (MET), which in turn is used to retrieve the calories burnt.

II-B Attacker Model

We assume that the webserver is honest, and is trusted by all participants. We assume adversaries that are able to launch the following types of attacks:

Inspect attacks. The adversary listens on the communications of trackers, bases and the webserver.

Inject attacks. The adversary exploits solution vulnerabilities to modify and inject messages into the system, as well as to jam existing communications.

Capture attacks. The adversary is able to acquire trackers or bases of victims. The adversary can subject the captured hardware to a variety of other attacks (e.g., Inspect and Inject) but cannot access the memory of the hardware. We assume that in addition to captured devices, the adversary can control any number of trackers and bases (e.g., by purchasing them).

JTAG attacks. JTAG and boundary scan based attacks (e.g., [22]), extend the Capture attack with the ability to access the memory of captured devices. We focus here on “JTAG-Read” (JTAG-R) attacks, where the attacker reads the content of the entire tracker memory.

II-C Reverse Engineering Fitbit and Garmin

Our goal in reverse-engineering the Fitbit Ultra and Garmin Forerunner protocols was dual, (i) to understand the source(s) of vulnerabilities and (ii) to develop security solutions that are interoperable with these protocols. Sec. 103(f) of the DMCA (17 U.S.C. § 1201 (f)) [23] states that a person who is in legal possession of a program, is permitted to reverse-engineer and circumvent its protection if this is necessary in order to achieve “interoperability”.

To log communications between trackers and webservers, we wrote USB based filter drivers and ran them on a base. We have used Wireshark to capture all wireless traffic between the agent software and the webserver. To reverse engineer Fitbit, we exploited (i) the lack of encryption in all its communications and (ii) libfitbit [24], a library built on ANT-FS [25] for accessing and transferring data from Fitbit trackers. Unlike Fitbit, Garmin uses HTTPS with TLS v1.1 to send user login credentials. However, similar to Fitbit, all other communications are sent over plaintext HTTP.

Fitbit and Garmin bases both use service logs, files that store information concerning communications involving the base. Garmin’s logs consist of an “authfile” for each tracker that was paired with the base, and .FIT files. The authfile contains authentication information for each tracker. Forerunner maintains 20 types of .FIT files, each storing a different type of tracker data, including information about user activities, schedules, locations and blood pressure readings. On the Windows installation of the Fitbit software, daily logs are stored in cleartext in files whose names record the hour, minute and second corresponding to the time of the first log occurrence. Each request and response involving the tracker, base and social network is logged and sometimes even documented in the archive folder of that log directory.

In the following, we first focus on Fitbit’s tracker memory organization and communication protocol.

Fitbit: Tracker memory organization. A tracker has both read banks, containing data to be read by the base and write banks, containing data that can be written by the base. The read banks store the daily user fitness records. The write banks store user information specified in the “Device Settings” and “Profile Settings” fields of the user’s Fitbit account. The tracker commits sensor values (step, floor count) to the read bank once per minute. The tracker can store 7 days worth of 1-per-minute sensor readings [26].

The webserver communicates with the tracker through XML blocks, that contain base64 encoded commands, or opcodes. tracker. Opcodes are 7 bytes long. We briefly list below the most important opcodes and their corresponding responses. The opcode types are also shown in Figure 2.

• •

Retrieve device information (TRQ-REQ): opcode [0x24,000000]. Upon receiving this opcode from the webserver (via the base), the tracker sends a reply that contains its serial number (5 bytes), the hardware revision number, and whether the tracker is plugged in on the base.

• •

Read/write tracker memory (READ-TRQ/WRITE). To read a memory bank, the webserver needs to issue the READ-TRQ opcode, [0x22, $index$,00000], where $index$ denotes the memory bank requested. The response embeds the content of the specified memory bank. To write data to a memory bank, the webserver issues the WRITE opcode [0x23, $index$, $datalen$,0000]. The payload data is sent along with the opcode. The value $index$ denotes the destination memory bank and $datalen$ is the length of the payload. A successful operation returns the response [0x41,000000].

• •

Erase memory: (ERASE) opcode [0x25, $index$, $t$, 0]. The webserver specifies the $index$ denoting the memory bank to be erased. The value $t$ (4 bytes, MSB) denotes the operation deadline - the date until which the data should be erased. A successful operation returns the response [0x41,000000].

Fitbit: The communication protocol. The communication between the webserver and the tracker through the base, is embedded in XML blocks, that contain base64 encoded opcodes: commands for the tracker. All opcodes are 7 bytes long and vary according to the instruction type (e.g., TRQ-REQ, READ-TRQ, WRITE, ERASE, CLEAR). The system data flow during the data upload operation is shown in Figure 2.

Upon receiving a beacon from the tracker, the base establishes a connection with the tracker. 2. 2.

Phase 1: The base contacts the webserver at the URL HOME/device/tracker/uploadData and sends basic client and platform information. 3. 3.

Phase 2: The webserver sends the tracker id and the opcode for retrieving tracker information (TRQ-REQ). 4. 4.

The base contacts the specified tracker, retrieves its information TRQ-INFO (serial number, firmware version, etc.) and sends it to the webserver at HOME/device/tracker/dumpData/lookupTracker. 5. 5.

Phase 3: Given the tracker’s serial number, the webserver retrieves the associated tracker public id (TPI) and user public id (UPI) values. The webserver sends to the base the TPI/UPI values along with the opcodes for retrieving fitness data from the tracker (READ-TRQ). 6. 6.

The base forwards the TPI and UPI values and the opcodes to the tracker, retrieves the fitness data from the tracker (TRQ-DATA) and sends it to the webserver at HOME/device/tracker/dumpData/dumpData. 7. 7.

Phase 4: The webserver sends to the base, opcodes to WRITE updates provided by the user in her Fitbit social network account (device and profile settings, e.g., body and personal information, time zone, etc). The base forwards the WRITE opcode and the updates to the tracker, which overwrites the previous values on its write memory banks. 8. 8.

The webserver sends opcodes to ERASE the fitness data from the tracker. The base forwards the ERASE request to the tracker, who then erases the contents of the corresponding read memory banks. 9. 9.

The base forwards the response codes from the tracker to the webserver at the address

HOME/device/tracker/dumpData/clearDataConfigTracker. 10. 10.

The webserver replies to the base with the opcode to CLOSE the tracker. 11. 11.

The base requests the tracker to SLEEP for 15 minutes, before sending its next beacon.

II-D Crypto Tools

We use a symmetric key encryption system. We write $E_{K}(M)$ to denote the encryption of a message $M$ with key $K$. We also use cryptographic hashes that are pre-image, second pre-image and collision resistant. We use $H(M)$ to denote the hash of message $M$. We also use hash based message authentication codes [27]: we write $Hmac(K,M)$ to denote the authentication code of message $M$ with key $K$.

III Fitbit and Garmin Attacks

During the reverse engineering process, we discovered several fundamental vulnerabilities, which we describe here. We then detail the attacks we have deployed to exploit these vulnerabilities, and their results.

III-A Vulnerabilities

Fitbit: cleartext login information. During the initial user login via the Fitbit client software, user passwords are passed to the webserver in cleartext and then stored in log files on the base. Figure 3 shows a snippet of captured data, with the cleartext authentication credentials emphasized. Garmin uses encryption only during the login step.

Fitbit and Garmin: cleartext HTTP data processing. For both Fitbit and Garmin, the tracker’s data upload operation uses no encryption or authentication. All the tracker-to-webserver communications take place in cleartext.

Garmin: faulty authentication during Pairing. The authentication in the Pairing procedure of Garmin assumes that the base follows the protocol and has not been compromised by an attacker. The authentication process is not mutual: the tracker does not authenticate the base.

III-B The FitBite and GarMax Tools

We have built FitBite and GarMax, tools that exploit the above vulnerabilities to attack Fitbit Ultra and Garmin Forerunner. FitBite and GarMax consist of separate modules for (i) discovering and binding to a nearby tracker, (ii) retrieving data from a nearby tracker, (iii) injecting data into a nearby tracker and (iv) injecting data into the social networking account of a tracker owner. We have built FitBite and GarMax over ANT-FS, in order to connect to and issue (ANT-FS) commands to nearby trackers. The attacker needs to run FitBite or GarMax on a base he controls.

The time required to search and bind to a nearby tracker varies significantly, but is normally in the range of 3-20 seconds. On average, the time to query a tracker is 12-15s. More detailed timing information is presented for the attacks presented in the following. We conclude that these attacks can be performed even during brief encounters with victim tracker owners.

III-C Attacks and Results

Tracker Private Data Capture (TPDC). FitBite discovers tracker devices within transmission range and captures their fitness information: Fitbit performs no authentication during tracker data uploads. We exploit Garmin’s assumption of an honest base to use GarMax, running on a corrupt base, to capture data from nearby trackers. We show how GarMax binds a “rogue” base agent to Garmin trackers of strangers within a radius of 33ft. GarMax exploits the authentication vulnerability of Garmin’s Pairing procedure (see Section III-A).

During the tracker authentication and passkey retrieval step of the Pairing procedure (see Section II-C), GarMax running on an attacker controlled base, retrieves the TPI of the nearby victim tracker. It then creates a directory with the TPI name and creates an auth file with a random, 8 byte long passkey. GarMax verifies the tracker’s serial number and other ANT parameters, then reads the passkey from the auth file. Instead of running the passkey authentication method, GarMax directly downloads fitness information (to be stored in .FIT files) from the tracker. This is possible since the tracker assumes the base has not been corrupted, and thus does not authenticate it.

TPDC can be launched in public spaces, particularly those frequented by fitness users (e.g., parks, sports venues, etc) and takes less than 13s on average. It is particularly damaging as trackers store sensor readings (i) with high frequency (1-9 seconds for Garmin, 1 minute for Fitbit), and (ii) for long intervals: up to 7 days of fitness data history for Fitbit and up to 1000 laps and 100 favorite locations for Garmin. The data captured contains sensitive user profile information and fitness information. For Garmin this information is tagged with GPS locations. Table I summarizes the information captured by FitBite and GarMax.

Figure 4 shows the reconstructed exercise circuit of a victim, with data we recovered from a TPDC attack on Garmin. The GPS location history can be used to infer the user’s home, locations of interest, exercise and travel patterns.

Tracker Injection (TI) Attack. FitBite and GarMax use the reverse engineered knowledge of the communication packet format, opcode instructions and memory banks, to modify and inject fitness data on neighboring trackers. On average, this attack takes less than 18s, for both FitBite and GarMax. Figure 5 shows a sample outcome of the TI attack on a victim Fitbit tracker, displaying an unreasonable value for the (daily) number of steps taken by its user.

User Account Injection (UAI) Attack. We used FitBite and GarMax to report fabricated fitness information into our social networking accounts. We have successfully injected unreasonable daily step counts, e.g., 12.58 million in Fitbit, see Figure 6. Fitbit did not report any inconsistency, especially as the corresponding distance we reported was 0.02 miles! The UAI attack takes only 6s on average.

Similarly, GarMax fabricates an activity file embedding the attacker provided fitness data in FIT/TCX [29] format. The simplest approach is to copy an existing activity file of the same or another user (made publicly available in the Garmin Connect website) and modify device and user specific information. We have used GarMax to successfully inject “running” activities of 1000 miles each, the largest permissible value, while keeping the other parameters intact.

Free Badges and Financial Rewards. By successful injection of large values in their social networking accounts, FitBite and GarMax enable insiders to achieve special milestones and acquire merit badges, without doing the required work. Figure 6 shows how in Fitbit, the injected value of 12.58 million steps, being greater than 40,000, enables the account owner to acquire a “Top Daily Step” badge. Furthermore, by injecting fraudulent fitness information into Earndit [28], an associated site, we were able to accumulate undeserved rewards, including 200 Earndit points, redeemable for a $20 gift card.

Battery Drain Attack. FitBite allows the attacker to continuously query trackers in her vicinity, thus drain their batteries at a faster rate. To understand the efficiency of this attack, we have experimented with 3 operation modes. First, the daily upload mode, where the tracker syncs with the USB base and the Fitbit account once per day. Second, the 15 mins upload mode, where the tracker is kept within 15 ft. from the base, thus allowing it to be queried once every 15 minutes. Finally, the attack mode, where FitBite’s TM module continuously (an average of 4 times a minute) queries the victim tracker. To avoid detection, the BM module uploads tracker data into the webserver only once every 15 minutes. Figure 7 shows our battery experiment results for the three modes: FitBite drains the tracker battery around 21 times faster than the 1 day upload mode and 5.63 times faster than the 15 mins upload mode.

In the daily upload mode, the battery lasted for 29 days. In the 15 mins upload mode, the battery lasted for 186.38 hours (7 days and 18 hours). In the attack mode, the battery lasted for a total of 32.71 hours. While this attack is not fast enough to impact trackers targeted by casual attackers, it shows that FitBite drains the tracker battery around 21 times faster than the 1 day upload mode and 5.63 times faster than the 15 mins upload mode.

Denial of Service. FitBite’s injection attack can be used to prevent Fitbit users from correctly updating their real-time statistics. The storage capacity of the Garmin tracker is limited to 1000 laps. Thus, an attacker able to injects a number of fake laps exceeding the 1000 limit, can prevent the tracker from recording the user’s valid data. A Fitbit tracker can display up to 6 digit values. When the injected value exceeds 6 digits, the least significant digits can not be displayed on the tracker. This prevents the user from keeping track of her daily performance evolution. In addition, for both Fitbit and Garmin, the attacker can render part of the recorded data useless, by injecting incorrect user profile information. For instance, by modifying user profile information (e.g., height, weight, see Section II-A), the attacker corrupts information built based on it, e.g., “calories burnt”.

IV A Protocol for Lightweight Security

IV-A Solution Requirements

We aim to develop a solution for low power fitness trackers that satisfies the following requirements:

Security. Defend against the attacks described in Section II-B. 2. 2.

Minimal tracker overhead. Minimize the computation and storage overheads imposed on the resource constrained trackers. 3. 3.

Flexible upload. Allow trackers to securely upload sensor information through multiple bases. 4. 4.

User friendly. Minimize user interaction. 5. 5.

Level tracker memory wear. Extend memory lifetime by leveling the wear of its blocks.

IV-B Public Key Cryptography: A No Go

We propose first FitCrypt, a solution to explore the feasibility of public key cryptosystems to efficiently secure the storage and communications of trackers. In FitCrypt, each tracker stores a public key. The corresponding private key is only known by the webserver. Each sensor data record is encrypted with the public key before being stored on the tracker. RSA with a 2048 bit key imposes a 4-hold storage overhead on Fitbit (each record of 64B is converted into a 256B record) and a 3.2-hold overhead on Garmin. We also consider ECIES (Elliptic Curve Integrated Encryption Scheme), an elliptic curve crypto (ECC) solution that uses a 224 bit key size, the security equivalent of RSA with 2048 bit modulus. ECIES imposes a storage overhead of $224+3r$ bits, where $r=112$ is the size of a security parameter. Thus, the storage overhead is 165% for Fitbit and 150% for Garmin).

When run on an Arduino Uno board, FitCrypt-RSA takes 2.3s and FitCrypt-ECC takes 2.5s to encode a single sensor record (see Table V, Section VIII). Garmin records sensor data with a frequency as high as one write per second. FitCrypt imposes a 250% overhead on the sensor recording task (of 2.5s every 1s interval), thus does not satisfy the second requirement of Section IV-A. To address this issue, in the following we introduce SensCrypt, a lightweight and secure solution for wearable trackers.

IV-C SensCrypt

We introduce SensCrypt, a lightweight protocol for providing secure data storage and communication in fitness centric social sensor networks.

Protocol overview. Let $U$ denote a user, $T$ denote her tracker, $B$ a base and $W$ the webserver. $T$’s memory is divided into records, each storing one snapshot of sensor data. The memory is organized using a circular buffer structure, to ensure an even wear. $T$ shares a symmetric key $K_{T}$ with $W$. $W$ also maintains a unique secret key $K_{W}$ for each tracker $T$.

To prevent Inject attacks, all communications between $T$ and $W$ are authenticated with $K_{T}$. To prevent Inspect, Capture and JTAG-R attacks, we encode each tracker record using two pseudo-random numbers (PRNs). One PRN is generated by $W$ using $K_{W}$ and written on $T$ during data sync protocols. The other PRN is generated by $T$ using $K_{T}$ at the time when the record is written on its memory. Both PRNs can later be reconstructed by $W$. This approach significantly increases the complexity of an attack: the attacker needs to capture the encoded data and both PRNs to recover the cleartext data.

IV-D The SensCrypt Protocol

Let $id_{U}$, $id_{B}$, and $id_{T}$ denote the public unique identities of $U$, $B$, and $T$. $U$ has an account with $W$. $W$ manages a database $Map$ that has an entry for each user and tracker pair: $Map[id_{U},id_{T}]$ = $[id_{U}$, $id_{T}$, $K_{T}$, $K_{W}$, $ctr]$. Each tracker is factory initialized with a symmetric key $K_{T}$ and a counter $ctr$ initialized to 1. $K_{T}$ and $ctr$ are also stored in $Map[id_{U},id_{T}]$. $K_{W}$ is a per-tracker symmetric key, kept secret by $W$. Table II summarizes these symbols for easy access.

SensCrypt consists of 2 procedures, $RecordData$ and $Upload$. $RecordData$ is invoked by $T$ to record new sensor data; $Upload$ allows it to sync its data with $W$. We now describe the organization of the tracker memory.

Tracker Memory Organization. Let $mem$ denote the memory of $T$. $mem$ is divided in “records” of fixed length (e.g., 64 bytes for Fitbit, 80 bytes for Garmin). Each record stores one report from the tracker’s sensors (see Section II-A). We organize time into fixed length “epochs” (e.g., 2s long for Fitbit, 1-9s long for Garmin). $RecordData$ records sensor data once per epoch. $mem$ is organized using a circular buffer. The dirty pointer is to the location of the first written record, and the clean pointer is to the location of the first record available for writing. When reaching the end of $mem$, both records “circle” over to the start pointer. Figure 8 illustrates the SensCrypt tracker storage organization, after the execution of various $RecordData$ and $Upload$ procedures. Algorithm 1 shows the pseudo-code of the procedures.

During $Upload$, each previously written tracker record is reset by $W$ to store a pseudo-random value (line 18 and lines 21-29 of Algorithm 1). That is, the $i$-th record of the tracker’s memory is set to hold $E_{K_{W}}(ctr,i)$, where $K_{W}$ is the secret key $W$ stores for $T$. The index $i$ ensures that each record contains a different value. $ctr$ counts the number of times $mem$ has been completely overwritten; it ensures that a memory record is overwritten with a different encrypted value.

The RecordData Procedure. Commit newly recorded sensor data $D$ to $mem$, in the next available record, pointed to by clean. $T$ generates a new pseudo-random value, $E_{K_{T}}(ctr,\textit{clean})$, and xors it into place with $mem[\textit{clean}]=E_{K_{W}}(ctr,clean)$ and $D$ (see line 10 of algorithm 1):

[TABLE]

The clean pointer is then incremented (line 11). When reaching the end of $mem$, clean circles back to start(lines 12,13). We call “red” the written records and “green” the records available for write. dirty and clean enable us to reduce the communication overhead of $Upload$ (see next): instead of sending the entire $mem$, $T$ sends to $W$ only the red records.

The Upload Procedure. We present the SensCrypt $Upload$ as an extension of the corresponding Fitbit protocol illustrated in Figure 2. In the following, each message $M$ sent between $T$ and $W$ is accompanied by an authentication value $Hmac(K_{T},M)$, where Hmac is a hash based message authentication code [27]. The receiver of the message uses $K_{T}$ to verify the authenticity of the sender and of the message. For simplicity of exposition, in the following we omit the Hmac value.

$Upload$ extends steps 6b and 7 of the Fitbit $Upload$. Specifically, when $T$ receives the READ-TRQ command (step 6a), it compares the dirty and clean pointers. If $\textit{dirty}<\textit{clean}$ (see Figure 8(a)), $T$ sends to $W$, through $B$,

[TABLE]

where $mem[dirty..clean]$ denotes $T$’s red memory area. For each record $i$ between dirty and clean, $W$ uses keys $K_{T}$ and $K_{W}$ and the current value of $ctr$ to recover the sensor data: $D[i]=mem[i]\oplus E_{K_{T}}(ctr,i)\oplus E_{K_{W}}(ctr,i)$ (see lines 21-23 and line 16). Then, in step 7 of Upload (see Figure 2), $W$ sends to $T$:

[TABLE]

$\forall i$=dirty..clean. $T$ uses $K_{T}$ to decrypt each $E_{K_{T}}(ctr+1,E_{K_{W}}(ctr+1,i))$ value. If the first field of the result equals $ctr+1$, $T$ overwrites $mem[\textit{dirty}+i]$ with $E_{K_{W}}(ctr+1,i)$ (see line 18), then sets dirty=clean(line 30). Thus, mem[dirty.. clean] becomes green. The case where clean $<$ dirty, occurring when clean circles over, past the memory end, is handled similarly, see lines 24-29 of Algorithm 1 and Figure 8(c) and (d). We eliminate the ERASE communication (steps 8 and 9 in Figure 2) from the Fitbit protocol.

V Analysis

V-A SensCrypt Advantages

SensCrypt ensures an even wear of tracker memory: the most overwritten memory record has at most 2 overwrites more than the least overwritten record. To see why this is the case, consider that once written, a record is not overwritten until a next $Upload$ takes place. The circular buffer organization of the memory ensures that all the memory records of the tracker are overwritten, not just the ones at the start of the memory. Using the example illustrated in Figure 8(d), notice that the first record, has been overwritten twice since the subsequent green blocks: once with $encData[1]$, see Figure 8(c), and once with the new $E_{K_{W}}(3,1)$ received from $W$.

By preventing excessive overwriting of records at the beginning of the memory, SensCrypt extends the life of trackers. This is particularly important for flash memories, that have a limited number of P/E (program/erase) cycles.

SensCrypt is user friendly, as the user is not involved in $Upload$ and $RecordData$ procedures. The SensCrypt base is thin, required to only setup standard secure SSL connections to $W$, and forward traffic between $T$ and $W$. SensCrypt imposes no storage overhead on trackers: sensor data is xor-ed in-place in $mem$.

V-B Security Discussion

Consider the life cycle of record $i$, $R_{i}$, on $T$. After the execution of the first $Upload$, $R_{i}$ is initialized with $E_{K_{W}}(ctr,i)$. When $R_{i}$ is overwritten with sensor data, it contains $encData[i]$ = $D[i]\oplus E_{K_{T}}(ctr,i)\oplus E_{K_{W}}(ctr,i)$. Subsequently, $R_{i}$ is not touched until an Upload takes place. During Upload, the (encoded) content of $mem[i]$ is sent to $W$, who subsequently overwrites $R_{i}$ with a new value: $E_{K_{W}}(ctr+1,i)$.

The base does not contribute to the messages it forwards between $T$ and $W$. Hence, the base does not need to be authenticated. The use of the $ctr+1$ value in communications through the base ensures message freshness.

Without $E_{K_{T}}(ctr,i)$, an Inspect adversary capturing communications between $T$ and $W$ cannot recover $mem[i]$. The use of HMACs with the key $K_{T}$ to authenticate communications between $T$ and $W$ prevents Inject attacks: an attacker that modifies existing messages or injects new messages cannot create valid HMAC values.

An attacker that launches a Capture attack against a victim tracker or base, cannot recover information from them and thus has no advantage over general Inspect and Inject attacks. An adversary that captures a tracker $T$ and launches a JTAG-R attack can either read $E_{K_{W}}(ctr,i)$ or $D[i]$ $\oplus$ $E_{K_{W}}(ctr,i)$ $\oplus$ $E_{K_{T}}(ctr,i)$, but not both. The use of the $E_{K_{T}}(ctr,i)$ value prevents an attacker from recovering $D[i]$. A JTAG-R attack against a captured, trusted base of tracker $T$ offers no advantage over Inspect and Inject attacks: in SensCrypt, the base only forwards traffic between $T$ and $W$. Similar to JTAG-R, a JTAG-RW attack against a captured tracker cannot decode previously encoded sensor data; it can however encode fraudulent data on the tracker (TI attack) and thus also inject data into $W$ (UAI attack).

An adversary able to perform Inspect, Capture and JTAG-R attacks can gain access to $E_{K_{W}}(ctr,i)$ when sent by $W$, then use JTAG-R to read $T$’s $K_{T}$, compute $E_{K_{T}}(ctr,i)$ and learn $D[i]$ (TPDC attack). We note the complexity of this attack. If able to further implement Inject attacks, the adversary can also succeed in a UAI attack.

Furthermore, SensCrypt is vulnerable to an adversary able to capture $T$ twice, at times $t_{1}$ and $t_{2}$. At time $t_{1}$ the adversary uses JTAG-R to read $E_{K_{W}}(ctr,i)$. At time $t_{2}$, assuming $T$ has already written record $i$, the adversary uses JTAG-R to read $mem[i]$ and $K_{T}$ and recover $D[i]$. This double JTAG-R attack is significantly more complex than a single JTAG-R attack. In addition, this attack is further complicated by time constraints: At $t_{1}$, record $i$ has not yet been written, and at $t_{2}$ it has been written but an Upload has not yet been executed. An Upload procedure before $t_{2}$ would overwrite record $i$ with $E_{K_{W}}(ctr+1,i)$, effectively thwarting this attack.

FitCrypt is resilient to TPDC attacks launched by adversaries capable of performing JTAG-R and Inspect, Inject and double JTAG-R attacks: $T$’s records encrypted with the public key can only be decrypted by $W$. Table III summarizes the comparison of SensCrypt and FitLock defenses. While providing more defenses (i.e., against TPDC for several attacker capabilities), FitLock is not a viable solution on most of the available trackers (see Section VIII).

VI Applications

SensCrypt can be applied to a range of sensor based platforms, where resource constrained sensors are unable to directly sync their data with a central webserver and need to use an Internet connected base. This includes a large number of popular fitness and home monitoring solutions. Table IV summarizes several such platforms, including the communication and storage capabilities of their sensors.

SensCrypt can also be used in applications where the sensors need to be immobile, while being able to operate without network connectivity. Examples include health, infrastructure, traffic, building and campus monitoring solutions. The bases through which the sensors sync with the webserver are mobile, e.g., smartphones of workers, who may become proximal to the sensors with the intention of data collection or as a byproduct of routine operations.

SensCrypt can also secure the data and communications of platforms for social psychological studies. One such example is SociableSense [30], a smartphone solution that captures sensitive user behaviors (including co-location), processes the information on a remote server, and provides measures of user sociability.

VII Sens.io: The Platform

We have built Sens.io, a prototype tracker, from off-the-shelves components. It consists of an Arduino Uno Rev3  [31] and external Bluetooth (Seeeduino V3.0) and SanDisk card shields. The Arduino platform is a good model of resource constrained trackers: its ATmega328 micro-controller has a 16MHz clock, 32 KB Flash memory, 2 KB SRAM and 1KB EEPROM. The Bluetooth card has a default baud rate of 38,400 and communication range up to 10m. Since the Arduino has 2 KB SRAM, it can only rely on 1822 bytes to buffer data for transmissions. The SD card (FAT 16) can be accessed at the granularity of 512 byte blocks.

The cost of Sens.io is $52 ($25 Arduino card, $20 Bluetooth shield,$2.5 SD Card shield, 4 SD card, see Figure [9](#S7.F9)), a fraction of Fitbit’s (99) and Garmin’s ($299) trackers.

SensCrypt. We have implemented a general, end-to-end SensCrypt architecture, as illustrated in Figure 10. We have implemented the tracker both in Arduino’s programming language (a Wiring implementation [32]), and, for generality, in Android. The base component (written exclusively in Android) is a simple communication relay. We implemented the webserver using Apache Tomcat 7.0.52 and Apache Axis2 Web services engine. We used the MongoDB 2.4.9 database to store the $Map$ structure. We implemented a Bluetooth [33] serial communication protocol between the tracker and the base.

The testbed. We used Sens.io for the tracker, an Android Nexus 4 with 1.512 GHz CPU for the base, and a 2.4GHz Intel Core i5 Dell laptop with 4GB of RAM for the webserver. We used Bluetooth for tracker to base communications and Wi-Fi for the connectivity between the base and the webserver. Figure 9 illustrates our testbed.

VIII Evaluation

We used Sens.io for the tracker, Android Nexus 4 with 1.512 GHz CPU for the base, and a 2.4GHz Intel Core i5 Dell laptop with 4GB of RAM for the webserver. We used Bluetooth for tracker to base communications and Wi-Fi for the connectivity between the base and the webserver. Figure 9 illustrates our testbed.

In the following, we report evaluation results, as averages taken over at least 10 independent protocol runs.

VIII-A Tracker: RecordData Overhead

We have investigated the overhead of the $RecordData$ procedure on Sens.io. Table V compares the performance of SensCrypt and FitCrypt, with times shown in milliseconds. We have explored two versions of FitCrypt, using RSA and ECC. FitCrypt-RSA with a 1024 bit modulus takes more than 500ms, but is currently obsolete. FitCrypt-RSA with a 2048 bit modulus hangs on Sens.io due to its low (2KB) RAM. The value shown in Table V is from [34], where a similar platform was used. FitCrypt-ECC uses ECIES, an elliptic curve cryptography solution, with a 224 bit key size, the security equivalent of RSA with 2048 bit modulus. FitCrypt-RSA 2048 and FitCrypt-ECC are not viable alternatives, imposing an overhead of 230% for 1 per sec. RecordData frequency. SensCrypt imposes however an overhead of less than 1% (6ms for each 1s interval between RecordData runs).

VIII-B Webserver: Storage Overhead

The webserver maintains a data structure, $Map$, with a record for each user and tracker pair. The entry consists of user, tracker and bases ids (8 byte long each), a salt (16B), password hash (28B), 2 symmetric keys (32B each) and a counter (1B). Assuming a single base in the $Bases$ list, a Map entry stores 133 bytes. For a 1 million user base, the webserver needs to store a $Map$ structure of 127MB. The average time to retrieve a record from a 1 million user $Map$ is 158ms.

VIII-C Upload: End-to-end Overhead

We consider a “Fitbit” scenario where the Upload procedure runs once every 15 minutes when in the vicinity of a base. Assuming a RecordData frequency of once every 2s (usual in Garmin), and a record size of 64B, SensCrypt uploads and overwrites 71 blocks of 512B each. The tracker side of the SensCrypt Upload procedure takes 502ms, dominated by the cost to read and write 71 blocks of data from/to the SD card. A single core of the Dell laptop can support 5 Uploads per second. The server cost is dominated by the 158ms cost of retrieving a record from a 1 million entry $Map$. The Upload/s rate of the webserver can be improved by caching the least recently accessed or most popular records of $Map$. Even though transferring over Bluetooth, the communication cost of SensCrypt’s Upload is 153ms. This is due to the low RAM available on Arduino for buffering packets (2KB).

SensCrypt’s total Upload time of 845ms is 400ms less than FitCrypt’s, assuming Fitbit’s memory size. We note however that Fitbit records data only once per minute, a rate at which SensCrypt would perform significantly faster. SensCrypt is 13 times faster (by more than 11s) than FitCrypt when considering Garmin’s memory (2000 blocks of 512B). This gain is due to SensCrypt’s optimization of only uploading the red, written blocks, instead of the entire memory.

Furthermore, even on the communication restricted Sens.io, SensCrypt reduces the upload operation of the real Fitbit equipment (1481ms on average) by 43%.

VIII-D Battery Impact

To evaluate the impact of SensCrypt on the battery lifetime, we powered the Sens.io device using a 9V alkaline battery [35]. In a first experiment, we evaluated the ability of SensCrypt to mitigate the effects of the battery drain attack. For this, we used the Bluetooth enabled Sens.io device to establish a connection with an Android app running on a Nexus 4 base. We investigated and compared two scenarios. In the first scenario, the Bluetooth enabled Sens.io runs the Fitbit protocol to process and respond to requests received every 15s. In the second scenario, the Sens.io device runs SensCrypt to process the same requests. Each scenario is performed using a fresh 9V battery.

When running Fitbit, the Sens.io device runs out of battery after 484 minutes. When running SensCrypt, the Sens.io device lasts for a total of 821 minutes. Thus, SensCrypt extends the battery lifetime of Sens.io under the battery depletion attack by 69%.

In a second experiment, we compared the impact of the periodic SensCrypt, FitCrypt-RSA-256 and Fitbit sensor data recording operations on the Sens.io battery lifetime. In the experiment, we considered a 2s interval between consecutive sensor recording operations. We have tested several RSA key sizes (2048 to 256 bit long). An (insecure) RSA key size of 256 bits was the largest value that did not hang on an Arduino board after only a few encryptions. We have also run a baseline experiment, measuring the battery lifetime of an Arduino board that is not recording any sensor data.

Figure 11 shows our results. In the Baseline scenario, the battery lasted 56 hrs and 23 mins. When running Fitbit’s sensor data record operation, the battery lasted 50 hrs and 18 mins. When running SensCrypt’s $RecordData$ operation, the battery lasted 43 hrs and 38 mins. Thus, Fitbit’s sensor recording operation shortens the battery by 10% over the baseline. SensCrypt’s $RecordData$ reduces the battery lifetime by 13% of the Fitbit battery lifetime. Finally, when running FitCrypt-RSA-256, the battery lasted only 22 hrs and 10 mins. Even with a vulnerable key size, FitCrypt reduces the battery lifetime by 49% of the SensCrypt lifetime. This confirms the unsuitability of public key cryptosystems to secure resource constrained fitness trackers.

IX Related Work

In the context of implantable medical devices (IMDs) Halperin et al. [10] introduce novel software radio attacks and propose zero power notification, authentication and key exchange solutions. Rasmussen et al. [12] propose proximity based access control solutions for IMDs. The different mission of fitness trackers creates different design constraints. First, unlike IMD security, where the focus is on authentication and key exchange, SensCrypt’s focus is on the secure storage and communication of tracker data. This is further emphasized by our need to also consider attackers that can perform Capture and JTAG-R attacks, for both trackers and bases (readers in the IMD context). While such attacks may not be possible for IMDs, and IMD readers may be expensive enough to afford tamper proof memory, these assumptions do not hold for most existing fitness centric social sensor network solutions. Furthermore, while additional user interaction may be naturally accepted for IMDs, fitness security solutions should minimize or even eliminate user involvement.

Tsubouchi et al. [9] have shown that Fitbit data can be used to infer surprising information, in the form of working relations between tracker carrying co-workers. This information could be used to surreptitiously learn the organizational profile of a company. This work assumes access to the fitness data of other users, a task that part of our paper undertakes.

Naveed et al. [13] introduced an “external device mis-bonding attack” for Bluetooth enabled Android health/medical devices, then collected sensitive user data from and fed arbitrary information into the user’s account. They developed Dabinder, an OS level defense that generates and enforces secure bonding policies between a device and its official app. Our work differs in the types and implementation of attacks, and in the solution placement: SensCrypt is implemented at the tracker and webserver, whereas Dabinder is focused on the base.

Lim et al. [36] analyzed the security of a remote cardiac monitoring system where the data originating from the sensors is sent through a Body Area Network (BAN) gateway and a wireless router to a final monitoring server. Muraleedharan et al. [37] proposed DoS attacks including Sybil [38] and wormhole [39] attacks, for a health monitoring system using wireless sensor networks. They introduced an energy-efficient cognitive routing algorithm to address such attacks. Our work differs through its system architecture, communication model and tracker capabilities.

Barnickel et al. [40] targeted security and privacy issues for HealthNet, a health monitoring and recording system. They proposed a security and privacy aware architecture, relying on data avoidance, data minimization, decentralized storage, and the use of cryptography. Marti et al. [41] described the requirements and implementation of the security mechanisms for MobiHealth, a wireless mobile health care system. MobiHealth relies on Bluetooth and ZigBee link layer security for communication to the sensors and uses HTTPS mutual authentication and encryption for connections to the backend.

X Conclusions

We identified and exploited vulnerabilities in the design of Fitbit and Garmin, to launch inspection and injection attacks. We presented SensCrypt, a secure and efficient solution for storing and communicating tracker sensor data. SensCrypt imposes minimal computation and communication overhead on trackers, and is resilient even to attackers able to probe the memory of captured trackers.

XI Acknowledgments

This research was supported in part by DoD grant W911NF-13-1-0142 and NSF grant EAGER-1450619.