Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

Kavya racharla ndh-naropanth_fin

270 visualizaciones

Publicado el

PacSec2017

Publicado en: Internet
  • Sé el primero en comentar

Kavya racharla ndh-naropanth_fin

  1. 1. WHEN ENCRYPTION IS NOT ENOUGH: 
 ATTACKING WEARABLE – MOBILE COMMUNICATION OVER BLE
 Kavya Racharla Sumanth Naropanth
  2. 2. Why are we here? Encryption != Security • Wearables Security • How things mess up when mobiles & wearables talk to each other • BT/BLE
  3. 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. 4. • The Facts
 
 • The Weakness
 
 • The Mitigation Agenda
  5. 5. • The Facts
 
 • The Weakness
 
 • The Mitigation Agenda
  6. 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. 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. 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. 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. 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. 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. 12. Object Model: • Main objects • CBCentralManager • CBPeripheral • CBPeripheralManager • CBCentral • Data objects • CBService • CBCharacteristic • Helper objects • CBUUID Core Bluetooth - iOS
  13. 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. 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. 15. Agenda • The Facts
 
 • The Weakness
 
 • The Mitigation
  16. 16. Wearables BT/BLE/ANT+ BT/BLE Back End Services HTTPS
  17. 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. 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. 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. 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. 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. 22. Example – Wearable Ecosystem 1
  23. 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. 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. 25. Example – Wearable 3
  26. 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. 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. 28. Agenda • The Facts
 
 • The Weakness
 
 • The Mitigation
  29. 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. 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. 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. 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. 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. 34. Mitigation Considerations • #apps to #wearable services mapping • Crypto support • Performance • Key management • Wearable • Phone • Cloud?
  35. 35. Demo – Fix
  36. 36. The Future • Android and iOS Security enhancements • Support for App to Device security • BLE Spec support for authentication and encryption • Both
  37. 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. 38. Thanks!
 (and Q&A) @kavyaracharla @snaropanth

×