Download as PDF, PPTX
Uploaded byShakacon
When Encryption is Not Enough...Sumanth Naropanth, Chandra Prakash Gopalaiah & Kavya Racharla
The document discusses the security vulnerabilities associated with mobile communication between wearables and devices using Bluetooth Low Energy (BLE). It highlights how encryption alone is insufficient for security, emphasizing various attack vectors such as man-in-the-middle and eavesdropping during the pairing process. The authors propose design and mitigation strategies to improve security and protect sensitive user data within the wearable and mobile application ecosystem.
More Related Content
Similar to When Encryption is Not Enough...Sumanth Naropanth, Chandra Prakash Gopalaiah & Kavya Racharla
![reductio [ad absurdum]](https://cdn.slidesharecdn.com/ss_thumbnails/taualywhssudecboubib-signature-40f4714a7511dbefb3f8b81978ee26a52b8bc17a56b46da771a1d673a5b4d7df-poli-170804175449-thumbnail.jpg?width=640&height=640&fit=bounds)
When Encryption is Not Enough...Sumanth Naropanth, Chandra Prakash Gopalaiah & Kavya Racharla
- 1. Shakacon VIII 2016 WHENENCRYPTION IS NOT ENOUGH: ATTACKING WEARABLE – MOBILE COMMUNICATION OVER BLE Sumanth Naropanth, Chandra Prakash Gopalaiah and Kavya Racharla
- 2. Why are wehere? Encryption != Security • Wearables Security • How things mess up when mobiles and wearables talk to each other • BT/BLE
- 3. 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. 4 Agenda The Facts The Weakness TheMitigation
- 5. 5 Agenda The Facts The Weakness TheMitigation
- 6. 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!
- 7. BT Classic vsBLE 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. 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. 9 How it works? AdAd Advertisin g interval Scanning Conn. Req. GATT Server Or Peripheral GATT Client Or Central Dat a Data Data Connectio n interval Dat a Broadcaster Observer
- 10. 10 Pairing Algorithms Secure SimplePairing • 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
- 11. BLE Security Pairing req. Capabilities, listof keys to be distributed and authentication requirements Pairing resp. TK STK Srand 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. 12 Core Bluetooth –iOS BLE Framework Object Model: • Main objects • CBCentralManager • CBPeripheral • CBPeripheralManage r • CBCentral • Data objects • CBService • CBCharacteristic • Helper objects • CBUUID
- 13. 13 Android - BLEsupport • 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. 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. 15 Agenda The Facts The Weakness TheMitigation
- 16.
- 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) ATTACKE R
- 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) ATTACKE R
- 20. Root Cause All applicationson 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 – WearableEcosystem 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
- 22. Example – WearableEcosystem 1 22
- 23. Example – WearableEcosystems 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
- 24. Example – Wearable3 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
- 25.
- 26. Why should wecare? 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. 27 Agenda The Facts The Weakness TheMitigation
- 28. 28 Objectives • Prevent malwareapp 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. 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
- 30. Mitigation Overview BLE Stack BLE Hardware BLE Stack BLEHardware 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. 31 Considerations • Multiple phonespairing to multiple wearable devices • One phone pairing to multiple wearable devices • Many phones pairing to one wearable device
- 32. 32 Design Flow 1 Applicationgenerates a random key and exchanges with wearable device Application generates a random key Received key from application Application exchanges key with wearable Secret Key Secret Key Same Value Key Exchange
- 33. Design Flow 2 Appon 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
- 34. Design Flow 3 Appon phone 1 Wearabl e Login LoginApp on phone 2 Cloud/Backend Services
- 35. Universal Solution 35 Operating systemproviding application to device pairing • Android and iOS support at the BLE service layer
- 36. 36 Corner cases • Wearablereset when out of Bluetooth range • Phone application uninstallation and installation • Rogue application on phone attempting to pair with wearable
- 37. 37 Post-OOBE Flows • Applicationand 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
- 38.
- 39. 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
- 40. Shout-outs: Eliza andAnto 40
- 41.