Vulnerability of Fitness Trackers: Risks They Are Facing and Tips to Minimize Them

Fitness trackers are everywhere, and their number will only be growing, with total shipments for trackers expected to reach 560 million in 2021. The data they are collecting is getting more and more valuable: now, besides simple sport interest, it is used in court and by insurance companies, offering bonuses for sharing fitness tracker data with them. As a result, preserving data privacy throughout the collection process and ensuring correctness and authenticity of the records stored is getting a real challenge for device manufacturers and IoT market players. What security problems are hidden in fitness trackers – and how can they be tackled?  

In-built Insecurity – or Lack of Care?

There are many reasons why fitness trackers have often been found extremely vulnerable by security specialists:
  • Lack of testing. New players are coming, and new products are released regularly. As a result, device manufacturers, including the market’s leaders like Apple, Xiaomi and Fitbit, often try to launch a device on the market as soon as possible, without proper preliminary testing.
  • Size of the device. Most of fitness trackers are tiny, and manufacturers don’t want to put extra weight of security hardware on devices typically worn on the wrist.
  • Trying to keep costs down.  With developers keeping financial constraints in mind, wearable devices typically don’t have sufficient memory to accommodate the extra code necessary for strengthening their security.
However, today developers can no longer fight for the customer and neglect the security aspect of the product. Thus, in August 2018 Pentagon banned the use of fitness trackers, each of which possesses geolocation features, on military bases due to their exposure to data leaks. Besides, the sensitive data collected by a fitness tracker, is getting more diverse than real-time geolocation data, emails, contacts and other proprietary information on the device. For example, some fitness wearables allow their users to access their accounts at select financial institutions and make payments. The security problem is presented not just by a fitness tracker, but by its whole ecosystem. As announced by Michael Lynch, the Chief Security Officer for InAuth, ‘Even though the wearable itself may not be the primary target of an attack, its link to a mobile device creates another point of entry for cybercriminals to exploit – especially since wearables security is a relatively new frontier’.

Fitness Tracker Structure: Vulnerabilities of Each Element

To see where the problem lies, let’s check a typical fitness device ecosystem. It works in conjunction with an app, installed on a mobile phone, tablet or another Personal Computer Device (PCD), and a server. Given the size, the tracker is equipped with BLE and communicates with the app over it, while the app interacts with the server using HTTPS in most cases.

Fitness Tracker

A wearable device, usually wrist-worn (though other types include those worn on the shoe, the waist, or the upper arm), captures various statistics from its wearer and is programmed to motivate him or her for more physical activity. Most of the wearable devices often don’t possess a built-in security mechanism such as user authentication or PIN system protection features. They also tend to store data locally without encryption. This poor security management makes the device extremely vulnerable to cyberattacks, among which firmware attacks are some of the most ‘effective’ ones, as after the initial injunction they can control every single aspect of the device, including local data storage, now open to modification, encryption keys or Bluetooth functionality. Cybercriminals can inject arbitrary step count values into memory, and the tracker would send it to the server as valid encrypted frames.

Fitness Application

An app installed on a smartphone, tablet or another Personal Computing Device (PCD) acts as a proxy enabling a fitness tracker’s user to interact with his or her device and send the captured data to the server as well as to retrieve the data from the server and display it in the application.  

There are 2 main architecture types of implementing the app into the fitness device ecosystem:

  • App as a ‘dumb’ pipe between tracker and backend server. Within this structure the app simply passes on the data. In order to get ‘insights’ and visualization of the data, it needs to address the server. Here the data between the tracker and the server is communicated in end-to-end encrypted way, which minimizes the risks of attacks on unencrypted data on the PCD. As an example, Fitbit tends to make use of this architecture type.
  • App as interpreter of data sent by the tracker. Here an app has a much wider functionality and visualizes the data without enquiring the server, i.e. the PCD can show detailed statistics even without a working Internet connection. Within this structure, the server is used for more advanced analysis, syncing and sharing of the data. The Withings Health Mate application is an example of this approach to building a fitness tracker structure.

Server Part

The server stores the biggest amount of data and provides the end user with deep personal statistics when synchronized with the app and the device. It makes the server the most targeted element in the whole system, which can face numerous types of attacks: DDOS attacks, SQL injection, or back door attacks. Given the most sensitive nature of the data stored on the server side, these attacks lead to the biggest financial losses.
Not only can the physical parts of the system be exposed to risks. Multiple attacks take place at the connectivity level.

Tracker – App: BLE Vulnerabilities

Due to battery and size constraints, fitness trackers use BLE to transmit the collected data. For a fitness tracker to start using this connectivity protocol and connect itself to the mobile app, it needs to make itself discoverable to mobile devices by publicly broadcasting advertising packets.   Fitness tracking devices use advertising packets in order to allow the master device, i.e. the PCD, to connect to it. These advertising packets contain information like Media Access Control (MAC) address, connectability modes and TX (transmission) power level. When receiving an advertising packet, the PCD with the installed fitness application sends a Scan Request to the fitness tracker requesting additional information such as device local name, supported profiles, etc. The tracker responds with a Scan Response which contains this additional information not included in the initial advertising packet. The master device then establishes a connection using a Connect Request along with further exchange of information (e.g. sharing of keys for secure connection). An attacker can exploit this scheme and use a fitness tracker as an access point for extracting the data stored locally. For example, an attacker can simply make use of sniffers to steal unauthorized data by detecting the broadcast signals of a wearable device and listening in to the key exchange. As a consequence, there will be either financial loss, or the integrity of the collected fitness data will be under risk.

App – Server: Transmitting Data over HTTPS

Most mobile apps which work in conjunction with fitness trackers routinely encrypt their communications with the server each time the user signs up, logs in, logs fitness data, and other application events.   The attacks that can take place include man-in-the-middle and redirection attacks, which could cause data to be sent to the wrong server. By adopting HTTPS, fitness tracking companies are trying to shield the transmitted personal data (name, email, telephone number, location) from third parties, who would monitor or tamper with fitness data exchanged between users’ mobile applications and company servers.

Tips to Add Security to Fitness Trackers

For enterprises and start-ups standing behind each fitness tracker ecosystem, addressing security issues up from the start of the development process is crucial.

Security mechanisms to consider:

  • LE privacy implementation. One of the main connectivity protocol vulnerabilities is fixed Bluetooth MAC address. Changing it at a regular interval, for example, every 10 minutes, would eliminate one way by which the wearer’s presence could be persistently monitored. However, most fitness tracking companies do not design their devices to change their MAC addresses.
One of the way to enhance security in this issue is employing an Identity Resolving Key (IRK). Fitness wearable firmware would have a fixed, private IRK that would be exchanged with the mobile app with which the device is paired. In this scheme a fitness tracker would regularly generate a new MAC address based on the IRK, and the MAC address would only be resolved to the wearable by another device that has stored the IRK and has functionality enabling its resolution.
  • Adopting HTTPS and security pinning. As transmitting sensitive health data over the Internet without proper transmission security is one of the first reasons, facilitating man-in-the-middle attacks and replay attacks, these tools aid to minimize the risk of them. HTTPS would encrypt and secure transmitted data, while security pinning would allow to associate (‘to pin’) certain cryptographic identities like certificates with the server, so that, if any other identity is present, the connection would be aborted.
  • Introducing on-device encryption. Typically fitness tracker developers encrypt data starting from the moment it is transmitted from a fitness band to be decrypted when it reaches the company’s server. Encrypting data prior to its transmission, when the data is stored on the device itself, would significantly reduce the cybercriminals’ ability to modify recorded fitness data and tamper with it, making the integrity of the data more reliable.                 
  • Contacting an IoT embedded software development company with a portfolio of similar projects. However different fitness tracking projects can be, each needs an individual approach and special attention to every element of the fitness tracker ecosystem. A highly qualified team would build a structure with security-first approach in mind, which would considerably minimize data breach and data leakage risks. Here, at R-Style Lab, we have already launched projects which present an ecosystem of connected devices requesting a proven security level of each of its elements.
A number of fitness trackers in use is expanding, and customers are delivering more and more personal data to their devices.Though this technology benefits users, there are serious security loopholes  which create a serious obstacle of a further wider adoption of fitness wearables on the market. Recognizing these security problems and making attempts to overcome them is essential for each player on the fitness tracker market.
Did you like our post?

Subscribe to our monthly IoT digest!

Please, enter a valid email address
Please, agree with our privacy policy

Check out services we provide!

Get a Free Quote Now!

Popular Posts

Link copied to clipboard

Get 3 bonuses now!

Just Share Your Project Idea
(We'll Keep It Safe!)
& Get Your Bonuses for Free!

get for free now