Presentation Material
Abstract
Wearable platforms today enable rich, next-generation experiences such as secure payments, specialized sports tracking and precise location monitoring. Data collection is only the first step for these products. The real “user experience” is often the result of a complex mesh of interactions between wearables, smartphones, cloud-hosted array of web applications and analytics software. Designing and validating security for such ecosystems, the kind of which never existed until a few years ago, demands brand-new lines of thinking and security best practices. Wearables live and operate on the human body, collecting a wealth of personal data. This gives rise to new challenges in storing such data securely and conforming to privacy regulations, especially in a world where consumer privacy laws are so diverse. The Oakley Radar Pace is a head-worn real time, voice activated coaching system that creates and manages training programs for track running or cycling. The “coach” is an NLP-powered voice assistant on the eyewear. User can converse with it hands-free, and get advanced feedback on their performance. In our presentation, we talk about the security and privacy research that went into designing and developing Radar Pace, including a custom Security Development Lifecycle (SDL) that accounted for the three “branches” of the program: wearable, phone and the cloud. We present examples of vulnerabilities and privacy problems associated with such new classes of products. While the applications and use cases for wearables are limited only by the designers’ imagination, the best practices we have pioneered will be useful and can easily be reapplied by vendors creating new wearables and IoT products. The goal of our presentation is to educate attendees about shedding the old notions of privacy and Security Development Lifecycle when preparing for the products of the future, as well as to discuss interesting security vulnerabilities in such technologies Presentation Outline [1] What is Oakley Radar Pace? A short introduction to the Oakley Radar Pace : use cases, end-to-end architecture, communication protocols and technologies used by different components of the ecosystem (wearable, app and the cloud) [2] Challenging traditional Security Development Lifecycle (SDL) We discuss the shortcomings of the traditional SDL model and introduce a wearable/IoT-centric Security & Privacy Development Lifecycle (SPDL). We discuss how we reuse the good parts of traditional SDL, throw in enhancements to accommodate rapid execution for the next generation programs, and also factor privacy alongside security. Inputs and deliverables for each stage of the custom SDL are discussed in this section of the presentation. [3] Wearable hardware & firmware security paradigms We talk about wearable-specific hardware and firmware security topics: secure boot, secure over-the-air (OTA) updates, ports and interfaces lock-down (USB/UART/JTAG), etc. We discuss threats associated with each of these topics [4] Software security paradigms This section covers software security requirements and threats applicable to all three components of the wearable ecosystem: Mobile application, embedded RTOS on the wearable device, and the Cloud. Some of the topics covered in this section are: + Building a secure on-device coaching system that maintains user privacy and protects confidential information + Securely managing the transfer and storage of “conversation data” in the wearable device, mobile and the cloud + Securing communication between the wearable and the mobile app: potential pitfalls with the design of communication protocols, including Classic Bluetooth and BLE + Securing data at rest on the wearable + Secure key management on the wearable and in the cloud backend + Android and iOS security in the context of wearables + Securing common user interfaces: User and Admin portals + Authentication and vetting of third party applications intending to interact with the wearable [5] Privacy We will introduce the audience to privacy requirements for wearables, the importance of having a privacy plan and a privacy notice. Topics covered in this section are: + Defining biometric, personal data and personally identifiable information in a wearable context + Protecting such data + Privacy requirements for data retention and account deletion + Geo based privacy restrictions for collecting, storing and retaining data + Privacy restrictions based on the consumer age group + User account management [6] Demo We will use this portion of the presentation to demo some of the real world vulnerabilities that were discovered with the help of our custom SDL Demo 1: How a rogue application may manage to exploit the pitfalls of BT/ BLE spec adoption in smartphone platforms to snoop on the communication between a wearable and the mobile app, and to inject arbitrary commands into the wearable Demo 2: How the failure to adopt security best practices for Android and iOS may allow a malicious app to gain access to conversation details between the user and the coaching system Demo 2: How an attacker may exploit a vulnerability in the user portal to steal admin credentials and user data, affecting all the wearables in the field (no user interaction required for the exploit to be successful) [7] Security for white label products In this section, we will discuss how SDL & Privacy are different when a vendor builds and ships a product entirely by themselves, as against working on a white label product that will be branded and shipped by a partner firm. Particularly on the privacy side, this may mean that there is not just one entity acting as the data custodian, the data processor/user and the data owner. When these roles are different, it becomes imperative to define the privacy responsibilities for each of the involved entities.
AI Generated Summary
The presentation addressed security challenges in next-generation Internet of Things (IoT) and wearable devices, using a head-mounted “fitness coach” as a case study. It argued that traditional Security Development Lifecycle (SDL) frameworks are inadequate for these products due to aggressive market timelines, a proliferation of communication protocols, and heightened privacy sensitivities from constant personal data collection.
Key findings demonstrated that vulnerabilities often arise from ecosystem-wide interactions rather than isolated components. Three specific attack classes were detailed:
- Bluetooth Data Leakage: On Android and iOS, any application can subscribe to Bluetooth traffic without restriction, allowing a malicious app to intercept all activity data (steps, heart rate) and sensitive commands sent between a wearable and its legitimate companion app, even if the Bluetooth link is encrypted.
- Insecure Local Logging: A voice-coach application stored sensitive user dialogue logs and GPS-enabled workout files (in FIT format) as plaintext in public storage on the mobile device. This allowed any app to access, tamper with, or exfiltrate personally identifiable information (PII) and intellectual property.
- Cloud Portal XSS: A cross-site scripting vulnerability in a cloud portal’s user signup/profile pages (with a 30-character limit on name fields) was exploited via the “friend request” feature. By chaining multiple maliciously crafted requests, an attacker could execute script in a victim’s browser upon login, stealing session cookies and compromising the account without user interaction.
The speakers proposed a tailored “Security Privacy Development Lifecycle (SPDL)” as a process solution. It integrates privacy and legal considerations into every phase of an agile SDL, from pre-alpha architecture reviews and threat modeling through code analysis, penetration testing of identified privacy/security test cases, and a formalized incident response plan involving legal stakeholders.
Practical implications emphasize that security must be designed into the entire device-app-cloud ecosystem from the outset. Critical technical objectives include authenticating and verifying every message on device communication channels (not just initial pairing), storing all sensitive data in encrypted form using private application storage, enforcing strict input validation and output encoding on cloud interfaces to prevent XSS, and providing users with clear opt-in/opt-out controls for data collection and the ability to delete logged data. The core takeaway is that partial security is insufficient; end-to-end integrity across all interoperating components is essential to prevent a single flaw from compromising the entire product ecosystem.