1 Introduction

From 2014 to 2022, approximately 141 million Fitbit devices have been sold, generating a revenue of $13 billion. As of 2022, 37 million Fitbit users engage with their devices weekly, with 120 million users registered on the Fitbit app [1]. The Wearable device is rapidly gaining popularity. The market is expected to reach 114.4 billion USD by 2028 from an estimated 36.3 billion USD in 2020. The smartwatch was 41% from the wearable device in the US in 2022 [2]. Wearable devices allow users to monitor aspects of their health, typically, their weight, activities, food, exercise, and sleep. These devices use sensors to obtain fitness-related metrics [3], which are monitored over time. The Fitbit Blaze is such a device. The device comes with a support system, namely, a connection to a website for monitoring and a mobile app.

The Fitbit device is usually connected via Bluetooth to the client device (such as Mobile, Tablet, Laptop or PC) on which the Fitbit application is installed. In addition, the client can connect to the Internet with the Fitbit server via Wi-Fi, Ethernet or Mobile broadband 5G/4G/3G. Data from a Fitbit Blaze is first sent to the Fitbit Application in the client and is then forwarded to the Fitbit server. The fitness data is saved in the Fitbit Blaze device for one month and also saved in the Fitbit application and the Fitbit server [3].

The Fitbit Blaze examined in this investigation automatically measures a range of activities whenever the user is wearing it. These include steps taken, hourly activity, current heart rate, distance covered, floors climbed, calories burned and active minutes [3]. These form part of the stored and transmitted data.

Under Australian Privacy Law, this health information is regarded as sensitive information. Legally, this data must be protected with respect to Confidentiality, Integrity, and Availability (CIA) [4, 5]. Similar protections are required in other regions, such as the European Union [6]. The connections between the components that are essential in data transfer are (1) the Fitbit device, (2) the Fitbit app on the users’ phone (the client) and (3) the Fitbit server. This investigation used an Android tablet with the Fitbit application installed on it as a client. The client can connect to the Internet and the Fitbit server via Wi-Fi or mobile broadband, as shown in Fig. 1, with the data flow shown as a series of steps, from 1 to 6.

Fig. 1
figure 1

The standard Fitbit Blaze connection in the experiment

Full size image

All data sent between the Blaze and the Fitbit app in the client (a phone or computer) is via Bluetooth. Data transmission from the client to the Fitbit server [7] is encrypted [8]. For stored data, the Blaze holds detailed minute-by-minute information for 30 days, with daily summaries that the user can monitor in either the Blaze client or on a dashboard [3].

Fitbit device data have been obtained previously, for example, in several criminal cases: “Cops use murdered woman’s Fitbit to charge her husband” [9], “The Police Used The Fitbit Fitness Tracker Data To Investigate A Crime” [10], and more criminal stories in "Fitbit Evidence in True Crime Stories and the Occasional Civil Case"[11]. Therefore, we explored avenues for access to the data associated with the Fitbit device [12].

This paper will investigate whether unauthorized third parties can access the data directly from the transmission channel or activity tracker storage and investigate the possibility of accessing the data without connecting to the Fitbit server. We adopted the Man-In-The-Middle model to capture the health data by using Charles proxy. Then, we analysed the data to extract the encryption method, device MAC address, fitness data, the authentication key, the cryptographic key and the Nonce. We also compared our findings with previous research.

2 Challenges

The health data collected by the Blaze device belongs to the user. However, the Fitbit Blaze, the Fitbit app, smartphone, or computer, does not directly provide all the collected data to the user. Some data can be obtained only by paying for a Fitbit Premium service [13]. Therefore, this investigation posed the following questions:

  1. 1.

    Are the data transmissions protected against unauthorised access or modification?

  2. 2.

    What data are transmitted between the device and the server?

  3. 3.

    How much data can be collected by unauthorized access?

3 Motivation and contributions

This investigation examined possible methods for the user to get direct access to personal health data collected and stored in the Blaze activity tracker without interacting with the Fitbit website servers. We also explored whether encryption keys are needed to recover information and whether the keys could be obtained at some point in the device lifecycle [14, 15]. This raises questions about what is transmitted and who can access that information: is it possible for unauthorized third parties, to access these data directly or not?

The paper, “Getting access to your own Fitbit data”, by Schellevis described their analysis of the Fitbit Charger HR in 2016 [16]. The firmware image of the Fitbit Charge HR was captured during a firmware update and this firmware image was analysed. They used the Fitbit Charge HR activity tracker and reverse-engineered the cryptographic primitives to recover the authentication protocol. The cryptographic key was obtained from the Fitbit Android application used in the authentication protocol. A backdoor in version (18.102) was located in the firmware by comparing this version with (18.122) which was the latest version of the firmware at that time. This backdoor was removed in the latest firmware version (18.122). The device-specific encryption key was extracted by using this backdoor from the memory of Fitbit Charge HR. Their experiment did not implement the last step to obtain their fitness data directly from the Fitbit Charge HR [16].

The Fitbit Blaze device is a new model with newer technology and improved security features. Consequently, the challenge is more significant. In addition, the Fitbit Blaze is a Fitbit device and also a Smart Watch. Therefore, this paper includes the Fitbit device and the smartwatch (Fig. 2).

Fig. 2
figure 2

Fitbit Charge HR and Fitbit Blaze

Full size image

4 Related works

Previously, the operation of several fitness trackers (including Fitbit devices) was analysed regarding security[17, 18].Several typical are explained as follows.

Fitbit One privacy and security issues were studied by Rahman et al. in 2013. They also studied a famous fitness tracking system, FitBite, a software module that relies on reverse engineering of Fitbit’s data communication protocol, to undertake active and passive attacks. FitLock, a Fitbit attachment that protects against FitBite, was then suggested. FitLock has been executed, and FitLock has been conducted to introduce a bit of end-to-end overhead on Fitbit (2.4%). They also used several tools in that experiment, such as a Snapshot of a testbed for FitLock, consisting of BeagleBoard and Xperia devices used as Fitbit trackers [19].

In 2014, Cyr et al. investigated three objectives of the Fitbit process: the data Fitbit gathers from its users, data it supplies to its users, and techniques for retrieving data that are restricted to device owners. They examined Fitbit One with the Nexus 5 Android phone. They made significant progress toward each objective. The outgoing data collected about Fitbit users was determined, including nearby Fitbits’ MAC addresses. The Android application has access to step data with granularity down to a minute that was also discovered, but the user interface does not present this. After modifying the source code, the researchers revealed this data in the log. Their most successful technique consisted of reverse-engineering the Android application. Overall, a sensible reasonable level of privacy for user data was provided by Fitbit, but a structure that provided users with an easy-to-access technique for achieving the complete set of data registered by the device was preferred. They also used several tools in that experiment such as Charles Proxy, Ubertooth, Wireshark, Apkextractor, Baksmali and Dex2jar [8].

In 2016, Schellevis et al. collared the Fitbit Charge HR firmware image during a firmware update and analysed it. They used the Fitbit Charge HR activity tracker and reverse-engineered the cryptographic primitives to recover the authentication protocol. The cryptographic key was obtained from the Fitbit Android application used in the authentication protocol. A backdoor in version (18.102) was located in the firmware by comparing this version with the latest version of the firmware (18.122) at that time. This backdoor was removed in the latest firmware version (18.122). The device-specific encryption key was extracted from the memory of the Fitbit Charge HR using this backdoor. Their experiment did not implement the last step to obtain the fitness data directly from the Fitbit Charge HR. They used several tools in that experiment such as mitmproxy on Windows, IDA PRO, JD, apktool, and dex2jar [16].

In 2017, Fereidooni et al. examined the Fitbit One and the Fitbit Flex. They used Android phone devices as the client and determined that security via inscrutability was the strategy executed in the user activity synchronisation protocol executed on the Fitbit devices they analysed. Although difficult to diagnose, they reverse-engineered the message semantics. They also demonstrated how falsified user activity information could be inferred and claimed that, based on their findings, such attacks could be achieved at such a scale as to acquire economic improvement. They also documented a hardware attack vector that allows circumvention of the end-to-end protocol encryption current in the Fitbit firmware at that time (Flex 7.81), directing to spoofing of useful encrypted fitness data. Finally, they recommended approaches for avoiding matching incoming vulnerabilities in system techniques. They made use of several tools in that experiment such as mitmproxy on Linux, Wireshark, STN32 ST-LINK Utility, a digital multimeter, a soldering iron, thin gauge wire and flux, tweezers, a soldering heat gun, the ST-LINK/v2 in a circuit debugger/ programmer, and the STM32 ST-LINK utility [20].

In 2019, Different devices, such as Garmin Forerunner 110, a Generic low-cost HETP fitness tracker and a Fitbit Charge HR were have been analysed by MacDermott et al. for any potential digital proof in a forensically sound technique, determining files of attraction and site data on the device. Data accuracy and truth of the evidence were shown as a test run system wearing all of the devices permitted for data comparison investigation [21].

In 2020, Almogbil et al. guided the investigators in understanding what data are gathered by a Fitbit device such as the Alta tracker and Ionic smartwatch, how to control Fitbit devices and how to grab and forensically examine the devices using Autopsy Sleuth Kit, open-source tools and Bulk Extractor Viewer. In addition, the investigators needed to display how the data were acquired and to confirm that the data had not been changed during the examination [22].

Another research project conducted by Zhang et al. in 2020 analysed critical security and privacy features of three very commonly used health tracker devices, namely, Fitbit, Google Glass and Jawbone. They analysed the devices’ power, how they communicated and their Bluetooth pairing procedure with mobile devices. They also explored potential malicious attacks by hackers via Bluetooth networking. The results of their investigation showed how these devices authorise third parties to acquire sensitive information from the exact device location, with the potential for compromising users’ privacy. They analysed how user data security and privacy on wearable devices were breached by unauthorised people and the potential challenges to secure user data by comparing three wearable devices (Fitbit, Google Glass and Jawbone), attack types and security vulnerabilities [18].

Researchers published on 09th April 2024, reviewed 236 peer-reviewed articles that were published until 2024. They focus with wearable technology, security and privacy, including Fitbit devices. They attach possibilities and concentrate on risk for the sensitive personal data may be utilised with the obtained data. They gave a talk that highlighted many research prospects [23].

Another report published on 22nd March 2024, highlights the safety issues faced by people using medical devices or wearable devices. For instance, when unauthorized third parties steal health data by accessing to these devices, This will be dangerous for the wearable host. The report explained what is the problem and the solution. The health data is secured by four points. Monitor the system activities and detect if any abnormal activities happen and find any bug in the result. This will be discussed in more detail in the next section. Devices should be properly authenticated using a secure method so that only authorised users can access the data generated by the wearable. Users should also receive education on how to make their data more secure and why data security is crucial [24].

The study of this field has attracted many researchers due to the development of Fitbit technology. These studies can contribute to the understanding and overcoming of the privacy and security challenges associated with these devices.

5 Methodology and results

This investigation into data access included five primary devices with a Man-In-The-Middle (MITM) attack. Firstly, a wearable device such as Fitbit Blaze. A second device was the Client device, namely, a Samsung Tablet “Model number SM-P605”, running Android version: 4.4.2. Another device was MiTM: a “Lenovo Yoga 3 Pro-1370” laptop. Furthermore, individual access via a router was used. The final device was a Fitbit server via the Internet (the router).

5.1 Installing man in the middle (MITM) in the experimental setup

All firmware images and fitness data transmissions were captured for analysis for this experiment. A Man-in-The Middle (MiTM) device was installed to capture and copy all data transferred between the app on the client and the Fitbit server. The Charles Proxy was selected as the (MiTM) because it is easy to use [25]. It was installed in the Lenovo Windows PC laptop, as shown in Fig. 3. The solid arrows in Fig. 3 indicate communication pathways used for data transfer. The dashed arrow indicates that the Charles Proxy certificate was installed on the client.

Fig. 3
figure 3

Installing Man in The Middle (MiTM) in the experimental setup

Full size image

The Blaze and fitness data flow from the Blaze to the client (Android tablet) via inflow connection 1 in Fig. 3. The data flow to the router is by flow connection 2. Next, the typical data flow should be sent to the Fitbit server via the Internet. However, because the Charles Proxy was installed in the computer and the gateway set to the computer was put in the client, the data flow to the computer was through flow connection 3 and back to the router through flow connection 4, then to the Internet and the Fitbit server through flow connections 5 and 6. The flows in the reverse direction, from 7 to 12, are the responsibility of the Fitbit server to the Blaze.

Fig. 4
figure 4

The first firmware location in the capturing was encoded

Full size image

5.2 Obtaining data from the first firmware image

The first firmware image was obtained from the first update of the new smartwatch, with the first connection via the Internet [8]. An example of the image was obtained in this way using Charles Proxy. The first image is necessary for the client and the fitness data are sent to the server. The fitness data are sent in a data object called a megadump in the initial firmware on the smartwatch. The first transmission is not encrypted, but it was encoded, as shown in Fig. 4. The fitness data were encrypted after the first update [18]. By installing Charles Proxy as MiTM, the data remain evident in their interfaces.

5.3 The first firmware description

The JSON data format is used to transmit the firmware of the smartwatch via the Internet. This JSON data has one image with three attributes.

The first image had 2,823,580 characters. The image data were not encrypted but were base64 encoded. This format was noted previously in [16]. After decoding this data to hexadecimal, 1,572,864 hexadecimal characters = 786,432 hexadecimal bytes were obtained. This began with: “03 04 00 00 02 0e 00 00 00 c9 f0 23 b3 50 11 01 50 c3 00 00 01 42 5d de 6b 70 63 65 47 30 88 0e c5 3c fe 75 45 e5 13 a8 4f 71 c7 bd 1a f1 df d9 00 31 8e a8 ff 36 9a 6a 91 d3 c6 00 16 2e 61 39 16 d6 a0 8e 8e ba a4 eb 55 ba 89 ad 71 0b 03 65 a5 65 0c ba d8 aa f9 6b cf 75 fa e2 25 f1 88 ae 72 5a 5f 47 dc 92 a2 10 7c 19 c0 35.. ..”

After capturing the second and third connections, the image data obtained are displayed in Table 1.

Observations of the first twenty bytes in each of the first three images reveal some common elements. There are nineteen bytes in the first twenty bytes that are the same (the sixth byte differs). Also, the tenth to fifteenth bytes are the serial number of the smartwatch, namely, “c9f023b35011”, as shown in Fig. 5.

Table 1 Hexadecimal Representation Of The First, Second And Third Data Images
Full size table
Fig. 5
figure 5

The serial number is in the Blaze (left) and the data image (right)

Full size image

A similar observation was made in [16] concerning the Charge HR device. They obtained 16 bytes for the segment size, so we speculated that the segment size for the Blaze was also 16 bytes. A header of 20 bytes was speculated because it was similar in these three images. There were 786,432 hexadecimal bytes which are a multiple of 16. The remaining data for the footer was 12 bytes. Therefore, as discussed above, every device has a different firmware because everyone has a different serial number in the header. The instruction set used was deduced from information on the Tech Insights site [26] which stated that the Silicon Labs 32-Bit microcontroller is used in this type of smartwatch and this microcontroller has ARM Cortex-M3 48 MHz. In addition, ARM’s Flagship Cortex-M Class Processor has several specifications: Low Power, High Performance, Thumb-2 Instruction Set Architecture (ISA), 3-stage Pipeline Core Based for Harvard Architecture, and Reducing the 32-bit Footprint [27].

5.4 Firmware analysis of the encryption cipher

According to Schellevis et al., the data in the Fitbit devices are encrypted using either Advanced Encryption Standard (AES) or Extended Tiny Encryption Algorithm (XTEA) [16]. We searched the firmware images and did not find the value (0x9e3779b9), so we deduced it was not XTEA encryption. Also, by examining one file in the device image firmware using Charles Proxy, we found most Fitbit devices with their encryption methods were as displayed in Table 2.

Table 2 Fitbit Devices with their Encryption Methods
Full size table

The image firmware for the Fitbit Blaze device is encrypted using AES, as shown in Fig. 6.

Fig. 6
figure 6

The Fitbit Blaze with its encryption method AES in the data image

Full size image

5.5 Authentication mechanism

When the Fitbit/Blaze starts connecting with the Fitbit application in the Android Tablet via Bluetooth, the handshake starts using three steps (from Fitbit App to Fitbit/Blaze to Fitbit App) to create a secure connection between them. The Authentication Mechanism and the Authentication Key Computation will first be described in this section. The Fitbit Android application will then be extracted from the Android tablet and transferred to java files. Finally, the java files will be analysed to extract the Authentication key and the Nonce.

5.5.1 Authentication mechanism description

When the Fitbit/Blaze is paired to the Fitbit application in the Android tablet, the Fitbit application recovers the “authSubKey” and the “nonce” from the Fitbit server [8]. According to Demi [28] and Schellevis et al. [16], a completed version of the information was found, namely, the message format for the authentication handshake, as shown in Fig. 7. The Fitbit application authenticates to the Fitbit/Blaze with this handshake and vice versa. The handshake has three messages. The authentication key discovered was used by the Android tablet to calculate a CMAC with AES in CMAC-mode (Cipher-based Message Authentication Code) [29].

Fig. 7
figure 7

Authentication Bluetooth commands

Full size image

The first message is sent from the Android tablet to the Fitbit/Blaze (A in Fig. 7 and 8). A random value and the Nonce, which were received during the pairing process, were contained in this command [16]. The Fitbit/Blaze then derives the authentication key using the Nonce. Next, the calculation of the CMAC is installed with the authentication key. The CMAC is computed by using the random value input by the Fitbit application and the counter. A number is incremented in each authentication attempt in the Fitbit/Blaze. This CMAC and the counter are sent in the second message of the handshake (B in Fig. 7 and Fig. 8) [16].

Fig. 8
figure 8

Authentication Handshake

Full size image

The Fitbit application checks if the Fitbit/Blaze provided CMAC is valid after receiving this message. The final authentication message computes a CMAC of the counter and sends this CMAC to the Fitbit/Blaze (C in Fig. 7 and Fig. 8). Finally, the Fitbit/Blaze sends an acknowledgement that the authentication has succeeded [16].

5.5.2 The authentication key computation

The Fitbit/Blaze uses related keys [16]. The device key creates the authentication key in two key creation steps, as shown in Fig. 9. A constant is used as the input for the derivation in the first step. The Fitbit/Blaze uses the Nonce as the input in the second key creation step for the authentication key. The Fitbit application sends the Nonce to the Fitbit/Blaze in the first message of the authentication handshake, as shown in Fig. 8. Each key has a different context. The authentication key is available to the Fitbit application, and the Device key is known by the Fitbit/Blaze and Fitbit server. The subkey creates the key that is called in the Fitbit server. The device key could be computed using the master key as hypothesised [16].

Fig. 9
figure 9

Hierarchy of Encryption Keys

Full size image

The fitness data are encrypted using the block cipher AES in CBC mode. First, it is divided into blocks: Plaintext 1, Plaintext 2, …, Plaintext N. AES and the Key then encrypt Plaintext 1 and the result is XORed with Plaintext 2 before encryption with AES and the Key again. Next, the same steps occur with Plaintext 3, Plaintext 4 until arriving at Plaintext N, which is XORed with Ciphertext N-1 and the subkey then encrypts the result to obtain CMAC [30], as shown in Fig. 10.

Fig. 10
figure 10

Illustration of AES-CMAC

Full size image

5.5.3 Fitbit java files extraction from the fitbit application

Apk Extractor, dex2jar and jd-gui were used in this stage to transfer the Fitbit Android application to Fitbit java files.

  1. 1.

    The Fitbit application was acquired using the Apk Extractor tool in the Android tablet.

  2. 2.

    The apk file was renamed as a zip extension. The zip file was then extracted to a folder.

  3. 3.

    classes.dex, classes2.dex, classes3.dex, classes4.dex files were copied from the extracted folder and pasted to the dex2jar folder and the command window was opened in the same dex2jar folder directory.

  4. 4.

    dex2jar classes.dex, classes2.dex, classes3.dex, and classes4.dex were typed.

  5. 5.

    The jar files were opened after jd-gui.exe was opened. After source files were saved as an src extension, the source files were renamed as zip extensions. The zip file was then extracted to a folder.

There are several tools to open and search java files such as Notepad, Notpad++, IDA Pro, etc. Fig. 11 explains the process to get java files from the Fitbit application.

Fig. 11
figure 11

The process to get java files from the Fitbit app

Full size image

When the Blaze connects with the Android tablet via Bluetooth, the Fitbit application retrieves a “nonce” and an “authSubKey” from the Fitbit server [8, 16].

5.5.4 The fitbit java files analysis

Fitbit java files were analysed to study the computation of the message used in the authentication handshake. Four classes of directories were found in Fitbit application java files:

  1. 1.

    Class 1 directory: contains the Android java files.

  2. 2.

    Class 2 directory: contains the Fitbit data java files.

  3. 3.

    Class 3 directory: contains the Fitbit features java files.

  4. 4.

    Class 4 directory: contains the transferred data java files, see Table 3.

Table 3 com.fitbit.livedata.auth.a
Full size table

“authSubKey” creates a JSON object (btleClientAuthCredentials) that searches for TrackerAuthCredentials that requests (paramCipher, authSubKey, nonce), as displayed in Table 4. Read “authSubKey” from Fitbit device that information was found in the following link displayed in Table 5. JSONObject is an object which contains files that connect Fitbit and Android through Bluetooth. For example, one of these files called (UUID), can be located in the following link displayed in Table 6. Auth Sub Key: “55 8d fa 01 4f a8 41 05 9f 02 4e aa 93 e6 29 80”. From the first link above, Nonce can be found in Classes 1, the Android java files, then go to Nonnull, see Table 7. So, b is located in the MainActivity java file in Classes 1, displayed in Table 8. Nonce: “17432576”. This is explained in Fig. 12.

Fig. 12
figure 12

Authentication key and nonce extraction

Full size image
Table 4 com.fitbit.livedata.auth.TrackerAuthCredentials
Full size table
Table 5 com.fitbit.data.domain.device.TrackerType
Full size table
Table 6 com.fitbit.bluetooth.BluetoothLeManager
Full size table
Table 7 com.fitbit.protocol.serializer.a.q
Full size table
Table 8 com.fitbit.MainActivity
Full size table

5.5.5 Fitness data extraction from the fitbit application

Activity data such as heart, active minutes, distance, floors, steps, etc. can be collected from the Fitbit application, as shown in Fig. 13.

Fig. 13
figure 13

Activity details in the Fitbit app code

Full size image

5.5.6 Fitness data extraction from the captured image

Activity data such as heart, active minutes, distance, floors, steps, etc. can also be collected from the captured image. Many details can be found in the image file. For example, Fitbit devices have MAC addresses that never change [8]. Therefore, the Fitbit Blaze has a unique MAC address, namely, “184B2EBE7DCB”, as shown in Fig. 14 and Fig. 15.

Fig. 14
figure 14

MAC address for the Blaze device from the image

Full size image
Fig. 15
figure 15

Activity details in the image

Full size image

5.5.7 Connect without the internet

In this investigation phase, we explored options for access to the Fitbit data that could be conducted without an internet connection to the Fitbit servers. Therefore, we disconnected the Internet, the router and the computer to find any synchronisation and data transfer, as shown in Fig. 18.

When we tried to connect the Blaze with the Android tablet using Bluetooth to create synchronisation without the Internet, as shown in Fig. 16, no synchronisation was created between them. Furthermore, we could not connect when we tried to change the display shape. Pinging can be done from the computer (192.168.1.7) to the router (192.168.1.1), but it cannot be done to the Android tablet (192.168.1.9).

Furthermore, when we tried to expand the network by connecting the Blaze to the Android tablet using Bluetooth and the router using Wi-Fi to create synchronisation, we could ping from the laptop with the Android tablet and the router. However, there was no synchronisation between the Blaze and the Android tablet. Therefore, there was no captured image in Charles Proxy, as shown in Fig. 17. Pinging can occur from the computer (192.168.1.7) to the router (192.168.1.1) and also to the Android tablet (192.168.1.9). Therefore, synchronising any devices or transferring data in the network cannot be done without connecting to the Internet (Fitbit server). The handshake can be found between the computer and the Android tablet, and the Android tablet connected to the router, as shown in Fig. 19. The handshake can be found between the computer and the server, as shown in Fig. 20.

Fig. 16
figure 16

The Blaze and the Android tablet connection

Full size image
Fig. 17
figure 17

The network connection without the Internet

Full size image
Fig. 18
figure 18

The Total Network with Showing the Disconnect Points

Full size image
Fig. 19
figure 19

Handshake between the computer and the Android Tablet in Wireshark

Full size image
Fig. 20
figure 20

Handshake between the computer and the Fitbit Server in Wireshark

Full size image

6 Discussion and conclusion

This study investigated the possibility of accessing the fitness data in the Fitbit Blaze without connection to the Fitbit server. To date, there have been no existing work on this topic.

Fig. 21
figure 21

What, where, how we achieved our outcome???

Full size image

The Fitbit Blaze device connects with the Fitbit server via the Fitbit application on the client device (a computer or Mobile device). For example, we used a Samsung Tablet as a client and the Fitbit application was installed on it. The data transfer was unencrypted in the first connection between the Fitbit application and the Fitbit server. However, after the first connection, the data were encrypted.

Charles Proxy was installed as a Man in The Middle (MiTM) on a computer to capture the first communication, which was not encrypted, between the tablet and the Fitbit server and analysed later. Later connections were not encrypted because MiTM captured all connections (Fig. 21).

After analysing the first firmware image and other firmware images, which were captured and transferred from base64 format to hexadecimal format, we found the serial number for the device, the AES for the firmware encryption cipher, the MAC address for the device, the Firmware header, my profile file in the Fitbit server account, and fitness data (Fig. 21).

In another process, the Fitbit application was extracted from the Samsung tablet using Apk Extractor and transferred to Java code files using Dex2jar and JD.GUI tools in the computer. After these Java code files were analysed, we obtained the authentication key, Nonce and fitness data.

The fitness data can be obtained only from the Fitbit device, the Fitbit application and the Fitbit server. The Fitbit device saves the fitness data for up to thirty days and the Fitbit application and the Fitbit server save the fitness data indefinitely. Our experiment obtained the fitness data by analysing the firmware images and Fitbit Java code files. We also tried to extract the fitness data from the Fitbit Blaze directly by connecting the device to the computer via the charging cable, but without success (Fig. 21).

Schellevis et al. also extracted the authentication key from the Fitbit Charge HR device as we did. However, they extracted the encryption key from the firmware backdoor before the Fitbit company updated the firmware [16]. We expected it would be impossible to extract the encryption key from the Blaze device because this issue was addressed from version 18.122 in 2016. Cyr et al.extracted the authentication key and Nonce from the Fitbit One device [8].

We tried, but failed, to connect and transfer fitness data between the Fitbit Blaze and the Fitbit application without connecting to the Fitbit server over the Internet. We also attempted, but failed, to connect and transfer fitness data between the Fitbit Blaze and the Fitbit application, the router and MiTM in the computer without the Internet and the Fitbit server. Therefore, we could not find a method of fitness data transfer possible between the Fitbit device and the Fitbit application without an internet connection and the Fitbit server.

We have analysed the connection strategy based on previous research. Finally, we have compared our outcomes with previous research outcomes and analysed the differences. Last but not least, we recommend using a second computer as a client because it will be easier to analyse the Fitbit application in Windows than the Android or iOS systems.