Shakacon VIII 2016

WHEN ENCRYPTION IS NOT ENOUGH:

ATTACKING WEARABLE – MOBILE

COMMUNICATION OVER BLE

Sumanth Naropanth, Chandra Prakash Gopalaiah and Kavya Racharla

Why are we here?

Encryption !=

Security

• Wearables Security

• How things mess up when mobiles and wearables talk to each other

• BT/BLE

Who are we?

3

• Sumanth

Manager & Tech Lead – New Devices Group Security, Intel

Sun Microsystems & Palm

• Chandra

Sr. Software Engineer – New Device Group Security, Intel

Motorola Mobility

• Kavya

Sr. Software Engineer – New Device Group Security, Intel

Oracle & Qualcomm

4

Agenda

The Facts

The Weakness

The Mitigation

5

Agenda

The Facts

The Weakness

The Mitigation

Why Wearables/IoT?

• 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 : Linux powered rifle, Baby monitor and Wireless Car

hacks!

BT Classic vs BLE

7

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 data

Use Cases Wireless speakers, headsets Wearable devices, smart pay

systems

• Bluetooth 5 coming soon! 4x Range and 2x Speed

8

BLE Protocol Stack

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

9

How it works?

Ad Ad

Advertisin

g interval

ScanningConn.

Req.

GATT

Server

Or

Peripheral

GATT Client

Or

Central

Dat

a

Data Data

Connectio

n

interval

Dat

a

Broadcaster

Observer

10

Pairing Algorithms

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

BLE Security

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 : For device identity and privacy by the use of random addresses

• CSRK : Resolve a signature and authenticate sender

• Supported Algorithms

• ECDH for key exchange

• AES-CCM for encryption

12

Core Bluetooth – iOS BLE Framework

Object Model:

• Main objects

• CBCentralManager

• CBPeripheral

• CBPeripheralManage

r

• CBCentral

• Data objects

• CBService

• CBCharacteristic

• Helper objects

• CBUUID

13

Android - BLE support

• 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

14

Known security risks

• 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

15

Agenda

The Facts

The Weakness

The Mitigation

Wearables

16

BT/BLE/ANT

+

BT/BL

E

Back End

Services

HTTP

S

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)

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)

ATTACKE

R

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)

ATTACKE

R

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

Example – Wearable Ecosystem 1

21

• 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

Example – Wearable Ecosystem 1

22

Example – Wearable Ecosystems 2

23

• 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

Example – Wearable 3

24

• 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

Example – Wearable 3

25

Why should we care?

26

• Activity data and exercise modes

• Heart rate, 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…

Confidentiali

ty

• Malware executes commands on the device

• Changing device name to rogue values

• See list for more commands

Integrity

Availabilit

y

PR

Problems• Hot research topic

• BORE risk

27

Agenda

The Facts

The Weakness

The Mitigation

28

Objectives

• Prevent malware app on phone from sending malicious commands to the wearable

device

• factory reset

• BLE device name change

• put device into recovery/boot mode

• 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.

29

Assumptions & Non-Objectives

• Assumptions

• BLE pairing happens successfully between wearable and phone

• Out of the Box Experience(OOBE) happens with legit application

• Non-Objectives

• Rooted/Jailbroken phone is out of scope

• Other vulnerabilities which may be leveraged to break the application sandbox

• Rogue application on phone attempting to pair with wearable device

• Man-In-The-Middle attack during BLE pairing

Mitigation Overview

BLE

Stack

BLE Hardware

BLE

Stack

BLE Hardware

BLE Pairing

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

31

Considerations

• Multiple phones pairing to multiple wearable devices

• One phone pairing to multiple wearable devices

• Many phones pairing to one wearable device

32

Design Flow 1

Application generates a random key and exchanges with wearable device

Application generates a

random key

Received key from

applicationApplication exchanges

key with wearable

Secret Key Secret KeySame Value

Key

Exchange

Design Flow 2

App on

phone 1

Wearabl

e

Login LoginApp on

phone 2

User enters numeric

pin number

Cloud/Backend

Services

1. Application requests user

to choose pin number

2. User choses numeric pin

number

Design Flow 3

App on

phone 1

Wearabl

e

Login LoginApp on

phone 2

Cloud/Backend

Services

Universal Solution

35

Operating system providing application to device pairing

• Android and iOS support at the BLE service layer

36

Corner cases

• Wearable reset when out of Bluetooth range

• Phone application uninstallation and installation

• Rogue application on phone attempting to pair with wearable

37

Post-OOBE Flows

• Application and Wearable perform Challenge-Response mechanism

• Report error state upon challenge-response failure

• Authenticate/Encrypt data transmission between wearable and phone application

and vice versa

• AES for encrypting data

• HMAC_SHA256 etc. for authentication/integrity

Demo – Fix

38

Summary

39

• 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

Shout-outs: Eliza and Anto

40

Thanks!

(and Q&A)

41

{sumanth.naropanth, chandra.prakash.gopalaiah,

kavya.racharla} @intel.com