2009 - Locally Exploiting Wireless Sensors

### Overview Travis Goodspeed presents a deep technical evaluation of the security vulnerabilities in wireless sensor network hardware and ZigBee microcontrollers, including chips widely deployed in smart electric meters, industrial monitoring, and academic sensor deployments. Addressing the common misconception that hardware acts as a secure black box or that hardware-accelerated AES-128 alone guarantees security, Goodspeed demonstrates practical physical and local attacks to extract firmware, cryptographic keys, and bypass security locks.

### Key Topics - **Microcontroller Architecture vs. IT Security**: Embedded sensor devices lack traditional operating system defenses such as userland/kernel separation, address space layout randomization (ASLR), and dynamic linking. Code and kernel routines are statically linked, and peripherals map directly to memory addresses. - **First-Generation ZigBee Radios**: In first-generation architectures (such as the Chipcon/TI CC2420 and Ember EM2420), radios operate as separate peripherals communicated with via synchronous serial interfaces (SPI). Cleartext AES-128 keys transmitted from the host microcontroller to the radio can be captured using physical taps (e.g., 20-gauge hypodermic needles or total phase Beagle sniffers). - **Second-Generation SoC Vulnerabilities**: Second-generation chips integrate the radio and microcontroller onto the same die. Goodspeed reveals how both major implementations fail to protect stored keys: - *Ember EM250*: Incorporates an XAP2 core described in register-transfer level (RTL) code that omitted hardware protection fuses or lock bits for the JTAG/Insight interface, allowing an attacker to simply connect a debugger and dump full memory. - *Chipcon/TI CC2430 & CC2530*: Features an 8051 Harvard-architecture core. While a lock bit restricts JTAG commands to chip erasure, the erase command by design only purges flash memory and leaves RAM untouched. Because 8051 C compilers automatically copy constants and data from flash into data RAM at startup, erasing the flash unprotects the chip while leaving keys intact in RAM, allowing full extraction in seconds. - **Bootloader and Glitching Attacks**: For microcontrollers such as the TI MSP430, access protection fuses and bootloader passwords can be defeated. Goodspeed presents timing attacks on bootstrap loader (BSL) password checks and explains power/voltage glitching to force instruction skipping (e.g., turning a conditional jump into a fallthrough).

### Technical Details - **RAM Extraction & Key Recovery**: On the CC2430, dumping 8 KB of RAM reveals the 128-bit AES key (typically situated in the upper 4 KB due to power-state preservation). Using a sliding-window tool developed by Josh Wright in Python, brute-forcing the key position across RAM takes only 2 to 4 seconds. - **Compiler Workarounds**: Storing sensitive constants in flash using compiler directives like `__code` avoids moving keys into RAM, but this breaks standard C pointer compatibility and standard library functions like `printf`. - **Bootstrap Loader (BSL) Password Cracking**: The MSP430 bootloader password reuses the 16 interrupt vector table pointers (32 bytes total). Because unused handlers point to standard addresses or fill bytes and code aligns to even boundaries, the search space is drastically constrained. Measuring execution cycle timing differences (two cycles per correct byte match) narrows down the alphabet and allows reconstruction. - **Voltage Glitching**: CMOS logic switching thresholds depend on supply voltage. By intentionally dipping supply voltage on specific clock edges (multiplying clock frequencies via phase-locked loops or observing power dips), attackers can cause gate-level failures that bypass fuse checks or jump instructions.

### Takeaways - Embedded hardware cannot rely on cryptography alone; poor hardware architecture, compiler behavior, and unmaintained JTAG/bootloader interfaces completely undermine symmetric cipher security. - Hardware issues cannot be easily patched in the field due to slim manufacturing margins, lack of over-the-air update mechanisms, and inability to recall devices. - Mitigations include blowing hardware security fuses, randomizing interrupt vector tables to individualize BSL passwords per unit, and explicitly controlling memory placement to keep secrets out of unprotected RAM.