Trustworthy Smart Band: Security Requirement Analysis with Threat Modeling

As smart bands make life more convenient and provide a positive lifestyle, many people are now using them. Since smart bands deal with private information, security design and implementation for smart band system become necessary. To make a trustworthy smart band, we must derive the security requirements of the system first, and then design the system satisfying the security requirements. In this paper, we apply threat modeling techniques such as Data Flow Diagram, STRIDE, and Attack Tree to the smart band system to identify threats and derive security requirements accordingly. Through threat modeling, we found the vulnerabilities of the smart band system and successfully exploited smart bands with them. To defend against these threats, we propose security measures and verify that they are secure by using Scyther which is a tool for automatic verification of security protocol.

💡 Research Summary

The paper addresses the growing security concerns surrounding smart bands, which continuously collect sensitive personal data such as heart rate, activity levels, and sleep patterns. Recognizing that security must be built into the design rather than added as an afterthought, the authors adopt a systematic, three‑stage methodology: (1) threat identification through formal modeling, (2) derivation of concrete security requirements, and (3) verification of the proposed protections using an automatic protocol analyzer.

First, the authors construct a detailed Data Flow Diagram (DFD) that captures the four principal entities in a typical smart‑band ecosystem: the wearable device, the companion smartphone application, the cloud backend, and the end‑user interface. The DFD maps out all communication channels, including Bluetooth Low Energy (BLE) pairing, RESTful API calls over HTTPS, and over‑the‑air (OTA) firmware updates. Using this diagram as a foundation, they apply the STRIDE framework (Spoofing, Tampering, Repudiation, Information Disclosure, Denial‑of‑Service, Privilege Escalation) to each data store and trust boundary. The analysis reveals that the BLE pairing process is especially vulnerable to spoofing and tampering, while the cloud API suffers from potential information disclosure if TLS certificate validation is weak. Privilege escalation risks arise from overly permissive mobile‑app permissions, and denial‑of‑service attacks can be launched by flooding the device with connection requests that drain its limited battery.

To move from abstract threats to actionable attack scenarios, the authors develop an attack tree. Key branches include: (a) a nearby adversary capturing BLE advertising packets and replaying them to impersonate a trusted smartphone; (b) a malicious app installed on the user’s phone that gains BLE access, bypasses authentication, and exfiltrates sensor data; (c) a man‑in‑the‑middle (MITM) attack on the TLS channel that exploits missing certificate pinning; and (d) a compromised OTA update that injects malicious firmware when signature verification is absent. The authors implement proof‑of‑concept exploits for each branch, demonstrating that the identified vulnerabilities are not merely theoretical.

Guided by the threat analysis, the paper derives six high‑level security requirements: (1) mutual authentication between band and phone, (2) confidentiality of all in‑flight data, (3) integrity protection for messages, (4) enforcement of the principle of least privilege, (5) secure key storage and management, and (6) authenticated firmware updates. The authors propose concrete mechanisms to satisfy these requirements: BLE 5.0’s LE Secure Connections with Elliptic‑Curve Diffie‑Hellman (ECDH) for key exchange, AES‑GCM for authenticated encryption of sensor streams, HMAC‑based message authentication codes for integrity, Android/iOS permission hardening to limit BLE access, a Secure Element or TPM on the band for safeguarding long‑term keys, and digital signatures (e.g., ECDSA) for OTA packages with hash verification before installation.

To validate the security of the designed protocol, the authors model it in Scyther, an automatic tool for symbolic analysis of security protocols. Scyther’s exhaustive search confirms that an adversary cannot achieve any of the STRIDE‑listed attacks: mutual authentication prevents spoofing, the ECDH‑derived session keys render replay and MITM attempts ineffective, and the HMAC/AES‑GCM combination guarantees confidentiality and integrity even under active network control. Moreover, the OTA verification logic ensures that any firmware lacking a valid signature is rejected, thwarting the firmware‑tampering branch of the attack tree.

In conclusion, the study demonstrates a complete, repeatable workflow for building trustworthy smart‑band systems: start with rigorous threat modeling (DFD + STRIDE + attack tree), translate findings into precise security requirements, implement lightweight yet robust cryptographic controls suitable for low‑power wearables, and finally verify the design with formal tools. The authors suggest future work on long‑term field deployments, performance benchmarking of the cryptographic primitives on constrained hardware, and user‑centric studies to ensure that security measures do not degrade the seamless experience that makes smart bands popular. This comprehensive approach offers a practical blueprint for manufacturers and researchers aiming to secure the next generation of personal health wearables.