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
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
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
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
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?
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
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
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
