I'm working on a pair of hands-on Zigbee hacking workshops. The first, which I've submitted with Aurélien Francillon to ToorCamp involves the writing of advanced stack overflow attacks for the MSP430 and AVR microcontrollers. The second, which I've submitted to Defcon 17, involves a number of hands-on hardware attacks against Zigbee nodes. Both include the sniffing of AES128 keys from a CC2420 Zigbee radio, a procedure that I demonstrated informally at Source Boston and describe below.
The CC2420 is a popular Zigbee/802.15.4 radio, and it is found in many wireless sensor development kits. We'll be attacking its hardware-accelerated AES128 implementation, by taking advantage of the fact that keys must be loaded over the SPI bus.
In the photograph above, I've tapped one of three SPI pins of the CC2420 radio chip on a Telos B using a hypodermic syringe. SPI consists of four pins: SCL, MOSI, MISO, and !SS. SCL, the Serial Clock, is output from the master to synchronize communication with the slave. MOSI and MISO are data lins, Master Out Slave In and Master In Slave Out. !SS or Slave Select is an inverted line that indicates the selection of a particular slave chip. Here, we'll only be tapping SCLK and one of the data lines, as two syringes are much easier to hold that four. Ground is shared by USB, so it isn't critical that we tap it.
As seen on my portable scope below, the tapped pin is the SCL, the data clock. The clock stands out because it idles low, and because all pulses in a batch are of regular width. Unlike a system clock, the clock only cycles when data is being transported.
The remaining two pins, in the group of three, are data. As shown on the scope image below, SPI data lines idle high, and bits are measures on edges of the clock.
Now that the clock and data lines have been found, it is necessary to sniff the traffic using a bus adapter. Until SPI-sniffing firmware for the Hackaday Bus Pirate becomes available, I will continue to use the Total Phase Beagle I2C/SPI Protocol Analyzer. A screenshot of the Total Phase client follows.
All that remains to identify the key in use, or anything else sent over the bus, is to read the log. I will likely release scripts for doing so at Defcon.
10 comments:
This is a side channel attack and thus doesn't constitute 'breaking 802.15.4 AES128' per se as it is relevant to a specific device
Agreed; interesting, but it's simply about sniffing SPI lines; not 802.15.4. Requires physical access to the device(s).
Yes, I've used a Beagle a few times at work, I really like it. How are sure that you are synchronizing correctly every time without using a slave select (CSn)? I know it can be hard to hold that many probes, but why not just solder a wire down?
I don't think that scope grab is what you are looking for. The AES transactions should have 16 SCK pulses in a row, not 2 bursted 8 SCK ticks. Look at fig 9 of cc2420.pdf, you are going to need the CSn signal to properly frame the transactions.
"All security related data is stored little-endian, i.e. the least significant byte is transferred first over the SPI interface during RAM read or write operations."
Are you setup to have pre-knowledge of the key? How are you going the identify it in the SPI log? The only RAM signal brought out is DVDD_RAM pin. I guess you could current sense and trigger on the RD/WR assuming there is a descernable current spike.
@frankincense
Depending on the firmware running on the MSP430, it may take awhile for the second byte to be transferred to the CC2420. The delay isn't unusual. Also, unless the TelosB external ST dataflash chip is being used (unlikely in many applications, at least during runtime), checking for chip select isn't needed.
Also, identifying the key is trivial - just search for the right ram-write command and the relevant address.
This is of course a problem with any pre-shared key system.
@Yann Ramin,
Ahh, you got me, shouldn't have posted without doing the rest of my homework.
What type of portable scope do you use ?
The ZigBee Smart Energy Profile (SEP) uses certificates for secure communication. Simply knowing the link or network keys is pretty much useless unless you also have a certificate from the licensing body (Good luck, they are a royal pain in the a$$ even to those who are paying their exorbitant fees).
At this point, the vast majority of pilots and products out there that support SEP are based on the EM250, and not the TI CC2420. Utilities are requiring the security and standardization that the SEP provides.
I consider this blog to be cute. However, it has shown that politicians with mediocre minds will over react to anything that serves their purpose.
Hey Travis, whilst I think your efforts to uncover vulnerabilities in systems are applaudable, are you going to quit spreading FUD about how by reading an AES-128 key in a CC2420 "you could control not just that meter you stuck the needle into, but any meter in the system" (http://www.forbes.com/2009/04/29/smart-grid-legislation-technology-security-smart-grid.html?feed=rss_technology_security)?
If not, maybe you could explain how you could do this?
Bruce,
See my paper entitled Extracting Keys from Second Generation Zigbee Chips for details of how to extract data memory from all presently available Ember and Chipcon radios, including the EM250. All of data memory is exposed, making certificates just as easy to extract as keys.
--Travis
Post a Comment