Investigating data storage security and retrieval for Fitbit wearable devices

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

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

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

The first firmware location in the capturing was encoded

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 ImagesFig. 5

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

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

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

Fig. 6

The Fitbit Blaze with its encryption method AES in the data 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

Authentication Bluetooth commands

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

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

Hierarchy of Encryption Keys

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

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.

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

2.

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

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.

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

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

The process to get java files from the Fitbit app

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.

Class 1 directory: contains the Android java files.

2.

Class 2 directory: contains the Fitbit data java files.

3.

Class 3 directory: contains the Fitbit features java files.

4.

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

Table 3 com.fitbit.livedata.auth.a

“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

Authentication key and nonce extraction

Table 4 com.fitbit.livedata.auth.TrackerAuthCredentialsTable 5 com.fitbit.data.domain.device.TrackerTypeTable 6 com.fitbit.bluetooth.BluetoothLeManagerTable 7 com.fitbit.protocol.serializer.a.qTable 8 com.fitbit.MainActivity5.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

Activity details in the Fitbit app code

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

MAC address for the Blaze device from the image

Fig. 15

Activity details in the 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