Bluetooth Keyboards: Who Owns Your Keystrokes? Michael Ossmann ShmooCon 2010

I work for the government, but this presentation is based on my own work. Don't blame the government for any of this.

Certain commercial equipment, materials, and software are sometimes identified to specify technical aspects of the reported procedures and results. In no case does such identification imply recommendations or endorsement by the U.S. Government, its departments, or its agencies; nor does it imply that the equipment, materials, and software identified are the best available for this purpose.

Scope Bluetooth HID profile Mostly keyboards 2003 Bluetooth 1.2 Newer standards unused in keyboards I tested General vulnerabilities

Crypto-Gram-0302 Article about importance of authentication

“you probably don't want to use Bluetooth for that”

Anatomy Power switch Connect button LCD or LED Dongle with connect button Printed BD_ADDR

The connect button initiates a “virtual cable” between the dongle and keyboard Virtual cable != pairing

The HID Profile USB/HID over Bluetooth Encryption “support” required for keyboards Not required for mice Not required for hosts

HID operates over HCI between host (PC) and dongle. HID operates over the baseband (air) interface between dongle and device (keyboard)

Gr-bluetooth for baseband GNU Radio USRP/USRP2 USB dongles for HCI BlueZ tools I've tried to focus on assessment methods that can be done by good guys with dongles, but we should assume an attacker has a USRP or even better equipment

Boot protocol vs. report protocol Both from USB HID spec Boot protocol used by BIOS

Bluetooth HID boot mode Boot protocol used Optional USB HID emulation hid2hci Sometimes cleartext operation

Spectrogram of waveform captured with gr-bluetooth

Wireshark bluetooth baseband (btbb) plugin Included with gr-bluetooth Dissects baseband (air) interface

Btaptap Joshua Wright Included with gr-bluetooth Pulls keystrokes from pcap files (either baseband or HCI)

Beware boot mode Avoid it completely if you can Test it if you can't

Connect to device

Connect to host

HID Attack By Collin Mulliner xkbd-bthid hidattack BIOS vs. OS Stuff keystrokes over mouse connection Encryption optional

No link key, no service Test your devices to ensure authentication is required

How to get BD_ADDR

Kismet-BTSCAN By Mike Kershaw Included with Kismet Active scanning Finds discoverable devices (inquiry)

Kismet-Bluetooth Included with gr-bluetooth Passive monitor Requires USRP

How to get link key

Bthidproxy Man in the middle Plain dongles Sniff without a USRP Can add injection

Got encryption? Test your devices to ensure they initiate encryption

Apple keyboard firmware attack By K. Chen Black Hat USA 2009

Extra PSMs (Protocol Service Multiplexers) on Apple Wireless Keyboard One is used for firmware updates

Firmware update sequence

Modified firmware Proof of concept hack: changed the “Service Provider”

Pairing attacks Wool & Shaked Cracked PIN and link key 4-digit PIN cracked in 63 ms on Pentium IV

BTCrack By Thierry Zoller btpincrack By David Hulton Require: Master BD_ADDR Slave BD_ADDR Other parameters exchanged during pairing Assume master initiates pairing Assume slave has variable PIN

Exceptions Slave initiates pairing Swap order of arguments Responder has fixed PIN Slave BD_ADDR not observed Shaked & Wool assume it can be observed by forcing re-connection, but this is not always true Observe LAP Discover UAP Determine NAP Educated guess with BNAP BNAP Active role switch attack Try all NAPs

My favorite bug (BTCrack) PIN: 0000 If nobody else found this bug it is probably because people aren't cracking PINs

Only pair in Faraday cage

“a clear value-added security benefit to Bluetooth keyboards over existing wireless keyboards” - Bluetooth HID Profile I believe this is true, but it isn't saying much.

Future: Baseband injection Bluetooth Low Energy

Big thanks: Joshua Wright Dominic Spill Mike Kershaw K. Chen

Slides, links, code: http://ossmann.com/shmoo-2010

Bluetooth Keyboards: Who Owns Your Keystrokes?