This document discusses attacks on wearable-mobile communication over Bluetooth Low Energy (BLE). It notes that while BLE uses encryption, any app on a device can subscribe to the same BLE channels and characteristics as legitimate apps to access sensitive data or send commands. This poses a risk as malware could obtain private data like heart rate or put devices into recovery mode. The document proposes mitigations like app-to-device pairing to restrict access to only registered apps and using application-specific keys to protect command integrity and data confidentiality. Future enhancements to mobile platforms and BLE specifications are needed to better support authentication and encryption between apps and devices.

1. WHEN ENCRYPTION IS NOT ENOUGH:
ATTACKING WEARABLE – MOBILE COMMUNICATION
OVER BLE
Kavya Racharla
Sumanth Naropanth

2. Why are we here?
Encryption != Security
• Wearables Security
• How things mess up when mobiles & wearables talk to
each other
• BT/BLE

3. Who are we?
• Sumanth
• Security Research Manager & Tech Lead – New Devices Group, Intel
• Sun Microsystems & Palm
• Kavya Racharla
• Security Researcher — New Devices Group, Intel
• Oracle & Qualcomm

4. • The Facts
• The Weakness
• The Mitigation
Agenda

5. • The Facts
• The Weakness
• The Mitigation
Agenda

6. • IoT – connecting any device with an on/off switch to the internet
• Cost and low power consumption are significant considerations
• BT/BLE FTW!
• Connected world —>Huge amounts of data —> Lot of concerns
• Security on top of the list : Baby monitor, wearable and Wireless Car hacks!
Why Wearables/IoT

7. BT Classic vs BLE
Bluetooth Classic Bluetooth Low Energy
Range (theoretical) 100 m > 100 m
Power consumption 1 W 0.01 to 0.5 W
Peak current
consumption
<30 mA
<15 mA
Data rate 1-3 Mbit/s 1 Mbit/s
Radio Frequencies 2.4 GHz 2.4 GHz
Focus
Wireless protocol for
short range data
exchange
Low power consumption –
periodic exchange of small
amounts of dataUse Cases
Wireless speakers,
headsets
Wearable devices, smart pay
systems
• Bluetooth 5 is here! 4x Range and 2x Speed

8. GAP
Defines how devices discover, connect and create bonding
between them
SMP
Protocol for pairing and key distribution and authenticating other
device
Shared secrets can be managed and hence speed-up the
reconnection process
L2CAP
Multiplexing layer for BLE
GATT
Describes characteristics, services and type of attributes/ their
usage
ATT
Simple Client/ Server stateless protocol with rules for accessing
data on a peer device
BLE Protocol Stack

9. Ad Ad
Advertising
interval
Scanning
Conn.
Req.
GATT
Server
Or
Peripheral
GATT
Client
Or
Central
Data
Data Data
Connection
interval
Data
Broadcaster
Observer
How it works

10. Secure Simple Pairing
• Just Works: very limited/ no user interface
• Numeric Comparison: devices with display plus yes/no button
• Passkey Entry: 6 digit pin as the pass key
• Out Of Band: Use of an out of the band channel against MITM
attacks
Pairing Algorithms

11. Pairing req.
Capabilities, list of keys to
be distributed and
authentication
requirements
Pairing resp.
TK
STKSrand
Mrand
Distribute LTK, IRK
and CSRK over link
encrypted with STK
Further secure
communication on
channel encrypted
with LTK
IRK : LE privacy by the use of
random addresses
CSRK : Resolve a signature and authenticate
sender
Supported Algorithms
ECDH for key exchange
AES-CCM for encryption
BLE Security

12. Object Model:
• Main objects
• CBCentralManager
• CBPeripheral
• CBPeripheralManager
• CBCentral
• Data objects
• CBService
• CBCharacteristic
• Helper objects
• CBUUID
Core Bluetooth - iOS

13. •Introduced in the core Android framework in 4.3 or API Level 18
•Declaration of necessary permissions in the manifest
•“BLUETOOTH” permission
•necessary to perform any communication
•request/accept a connection, transfer data
•“BLUETOOTH_ADMIN” permission
•app to initiate device discovery
•manipulate Bluetooth settings
Android - BLE support

14. • Security largely depends on the chosen flavor of the pairing mechanism
• Passive attacks
• Eavesdropping on the pairing session compromises encryption keys
• Mike Ryan’s research: With Low Energy comes Low Security
• Just works vulnerable to active attacks
• MITM attacks: Just works mode
Known Security Risks

15. Agenda
• The Facts
• The Weakness
• The Mitigation

16. Wearables
BT/BLE/ANT+ BT/BLE
Back End
Services
HTTPS

17. The Problem – Prelude
Device Commands:
• Put device into recovery
mode
• Do a FW update
• Change Device (BLE) name
Notifications:
• Social apps
• Calls and texts
Information:
• User activity data
• User profile updates
• Application action (calls, music
control)
• Call/text/social updates
(sometimes)

18. The Problem – Prelude
Device Commands:
• Put device into recovery
mode
• Do a FW update
• Change Device (BLE) name
Notifications:
• Social apps
• Calls and texts
Information:
• User activity data
• User profile updates
• Application action (calls, music
control)
• Call/text/social updates
(sometimes)
BLE -
ENCRYPTED
ATTACKER

19. The Problem
Device Commands:
• Put device into recovery
mode
• Do a FW update
• Change Device (BLE) name
Notifications:
• Social apps
• Calls and texts
Information:
• User activity data
• User profile updates
• Application action (calls, music
control)
• Call/text/social updates
(sometimes)
BLE -
ENCRYPTED
ATTACKER

20. Root Cause
All applications on Android and iOS can subscribe to the BT
service and get the data on the same BT channels or BLE
characteristics as the legitimate app
• Android
• android.permission.BLUETOOTH
• android.permission.BLUETOOTH_ADMIN – quote:
• iOS
• Core Bluetooth (CB) Framework
• Centrals (client/phone) and Peripherals (server/wearable) classes

21. Example – Wearable Ecosystem 1
• Uses BLE
• Proprietary code
• Existing market research for format of messages and headers
• Malware app subscribes to the known BLE characteristics gets
data synced with the legit app

22. Example – Wearable Ecosystem 1

23. Example – Wearable Ecosystems 2
• Use BT, BLE and WiFi
• Device can sync directly to the cloud
• Fewer app-associated threats
• Malware app (GATT characteristics scan/read/write) does not
pick up any user information

24. Example – Wearable 3
• Similar, but with a twist
• Malware application cannot send commands to the wearable by itself
• Legitimate app opens a connection to the device
• The malware app piggybacks to send commands to the wearable
Moral: Partial security does not help
• Protect not just the handshake but every
message

25. Example – Wearable 3

26. Malware Proof of Concept
Wearable device sends heart rate data
continuously over BLE
if ((charaProp | BluetoothGattCharacteristic.PROPERTY_NOTIFY) > 0) {
mNotifyCharacteristic = characteristic;
mBluetoothLeService.setCharacteristicNotification(
characteristic, true);
}
return true;
}
public void onCharacteristicChanged(BluetoothGatt gatt,
BluetoothGattCharacteristic characteristic) {
final byte[] data = characteristic.getValue();
...
if (characterstics.equals("558dfa01-4fa8-4105-9f02-4eaa93e62980"))
{
int[] dataArray = new int[data.length];
int i = 0;
for (byte b : data)
dataArray[i++] = b & 0xff;
int steps = ((dataArray[5] & 0xff) << 8) | (dataArray[4] & 0xff);
int calories = ((dataArray[13] & 0xff) << 8) | (dataArray[12] & 0xff);
int heartRate = dataArray[18];
System.out.println("malware: Steps = "+ steps +" , calories = “+
calories +", HearRate = “+heartRate);
}
}
Malware app subscribes to the same
GATT profiles, captures the raw data
and parses to get useful personal data

27. • Activity data and exercise modes
• HR, calories, distance, skin temperature, etc.
• Fine-grained GPS patterns = user location
• Malware app puts the device into recovery mode
without a follow-up FW image
• User will need to take the device to a service
center to recover
• Change the device name to cause temporary DoS
“Malware on my phone?”
Never!
But…
Confidentiality
• Malware executes commands on the device
• Changing device name to rogue values
• See list for more commands
Integrity
Availability
PR Problems
• Hot research topic
• BORE risk
Why should we care?

28. Agenda
• The Facts
• The Weakness
• The Mitigation

29. Objectives
• Allow communication only between the legitimate application on the phone and the
wearable device
• Protect confidentiality of sensitive data sent from the wearable to phone
• activity data – HR, Calories, activity information, etc.
• Application specific feedback or inputs – music, notifications, etc.
• Protect integrity of all commands sent from the companion app to the wearable

30. Assumptions & Non-Objectives
• Out of the Box Experience (OOBE) occurs with the legit application
• Phone is not rooted/jail-broken
• Pre-existing application sandbox breaking vulnerabilities
• Man-In-The-Middle attack during BLE pairing

31. BLE Pairing
Mitigation Overview
Multiple
applications use
BLE link layer to
transmit data
Malware has access
to the same BLE
pairing as legit app
App to Device Pairing
App to device
pairing restricts
access to registered
app
BLE
Stack
BLE Hardware
BLE
Stack
BLE Hardware

32. Mitigation Design
Key Exchange - Application Specific Key Kp
Protect Integrity — HMAC(Kp, command)
Protect Confidentiality — E(Kp, data)
Ignorant of Kp. Cannot Read/Write

33. Mitigation — Real World
Web portal &
Services
Service A
Service B
Service C
Multipletrustedappsonmultipletrustedphones
Cloud-based
account & key
management
Wearable device
may offer services
to multiple apps

34. Mitigation Considerations
• #apps to #wearable services mapping
• Crypto support
• Performance
• Key management
• Wearable
• Phone
• Cloud?

35. Demo – Fix

36. The Future
• Android and iOS Security enhancements
• Support for App to Device security
• BLE Spec support for authentication and encryption
• Both

37. Summary
• Soft underbelly:
• Bluetooth/BLE Spec
• Adoption of the spec on popular smartphone platforms
• Medium Risk (malware on the phone); High Impact (sensitive user information)
• Severe impact for wearables with security and finance use cases
• Apple Watch Auto Unlock
• Pay
• Protecting from network attackers is not enough
• Onus on App developers and wearable OEMs to add an extra layer of security for
App <— —> Device communication

38. Thanks!
(and Q&A)
@kavyaracharla
@snaropanth