BLE Security Authentication Privacy Discussion EECS 582 -- Spring - PDF document

Overview BLE Refresher Attacks Improvements BLE Security Authentication Privacy Discussion EECS 582 -- Spring 2015 BLE: Quick/Simplified Refresh Link Layer State Machine Application Layer GATT ATT L2CAP Link Layer Physical Layer Link Layer Connections - Steps BLE CONNECT_REQ Packet 1. Initiate Connection 2. Exchange keys <- Attack! 3. Authenticate 4. Send encrypted messages

Initiating a BLE Connection Sniffing an on going connection ● Eliminate false positives (how do you know what is a packet) ● Peripheral advertises o Look for 16-bit header for empty packet, take prior 32-bits as AA o crcInit can be reversed, by running the packet through the LFSR in ● Initiator starts connection reverse (magic, magic, math, math...) o hopInterval o Access Address is set in each packet. o hopIncrement ● Wait on a channel and observe subsequent packets, record time between o accessAddress o crcInit ● Wait for a packet on two separate data channels ● Initiator and peripheral move to next channel Encryption - BLE 4.0 & 4.1 BLE 4.2 - Secure Simple Pairing ● Custom key exchange ● Elliptic Curve Diffie Hellman o Select TK (128 bit AES key) o 96 bits of entropy with P-192 or 128 bits with P-256 o Use TK to agree upon LTK ● Protects against passive eavesdropping ● What’s TK? ● Does not protect against MITM o Just Works TM : key == 0 o 6-digit passkey: key in 0-999,999 ● Association models (anti-MITM) o Out of Band: You’re on your own. o Numeric comparison o Out of Band o Passkey ● Secure Connections Only Mode Link Layer Encryption Could I be tracked? ● TCP/IP o No encryption ● Device Address Randomization o No authentication o Access Address generated by identity key (IRK) o Relies on application layer o IRK exchanged during bonding o Vulnerable to passive listener ● Do people use it? o “We do not currently employ Bluetooth Smart in this capability.” ● BLE o “...we do not use randomize device address.” o Node-to-node encryption o “As far as we are aware, our two products that use BLE do not utilize o Impractical authentication (for many IoT) this feature.” o Simply Secure is safe from passive listener

Summary Wishlist ● Proven link-layer encryption scheme node to node (in 4.2) ● Better way to do authentication o Many IoT class devices don’t have classical I/O ● No protection against MITM without traditional I/O o How to I control what devices are connected to my gateway? o How can I control what gateways I connect to? ● Option for randomizing device address ● Multihop communication o Do I trust the nodes in between the gateway and destination? o What happens if one of my devices is compromised? ● Do I trust my gateway? References What does IoT need? https://lacklustre.net/bluetooth/ ● Confidentiality o I don’t want people monitoring my habits at home Ryan_Bluetooth_Low_Energy_USENIX_WOOT.pdf ! ...but people can already see if my lights are on … https://eprint.iacr.org/2013/309.pdf Communication between nodes should be kept secret o https://www.bluetooth.org/DocMan/handlers/DownloadDoc.ashx? ● Authentication doc_id=286439 We want to know what nodes are on our network and that they’re legit. o ● Preventing pivots o If a node is compromised, it should be hard for that node to pop other devices. ● Do I want people to know what devices I have in my house? ● Prevent neighbors from turning off lights ● General framework that different classes of devices can “inherit” from: medical IoT can specify something that fitness IoT needn’t have.