Generic CC1110 Sniffing, Shellcode, and iClickers

Howdy y'all,

I haven't the time to write individual posts on these subjects, but I do have plenty of new features for the CC1110 that are worth sharing. Rather than explain how they were written in too much detail, I invite you to read the source code, which is mostly Python and C shellcode.

In order to follow along with these examples, you will need to have SmartRF Studio installed to /opt/smatrf7. While this requirement will go away in a few weeks, the GoodFET client temporarily needs SmartRF Studio for machine documentation about the CC1110. You can find more details on SmartRF requirements in the goodfet.cc client page.

(1) Packet sniffing, and other neighborly scripts.

GoodFETCC now has packet sniffing support for the SimpliciTI protocol used by the Chronos watch. Not only that, but it implements the protocol well enough to act as an access point for the watch, collecting accelerometer data and deciphering it for the host.


Run an access point with 'goodfet.cc simpliciti [band]'. (This command will likely change names soon, as it is a rather ugly hack which only supports the Chronos accelerometer feature.) The optional parameter should be us, eu, or lf for the American, European, and Low Frequency versions of the watch.


Not only protocols intended for the GoodFET, but also others which are coincidentally compatible, are supported. Thanks to some register settings contributed by Mike Ossman, you can sniff and decipher i<clicker traffic with 'goodfet.cc iclicker'.


The i<clicker uses a Xemics XE1203F (PDF) radio chip, shown below. The XE1203F is nearly as configurable as the CC11xx parts, except that it is limited to 2FSK encoding. Previously, this protocol could be sniffed with the GR-Clicker project and a USRP, but the highly-versatile CC1110 chip allows this to be done with neither a software defined radio nor a chip identical to that used by the transmitter.


If you find it handy to see when a device is broadcasting, you can produce an ASCII-art plot of signal strength with 'goodfet.cc rssi [freq]':


Care to jam another transmitter? Just like with the Next Hope Badge's GoodFET mode, it takes a single command to hold a carrier wave.
'goodfet.cc carrier [freq]'


(2) Shellcode, now for quiche-eaters!

At the risk of appearing to facilitate quiche-eating, I'd like to quickly explain the new shellcode interface for placing code fragments on a Chipcon 8051 target, such as the CC1110.

The Chipcon radios have certain functions which are timing sensitive, chief among these being the rewriting of flash memory and the use of the digital radio core. If flash memory is not pulsed with the correct timing, mis-writes will occur. If the radio is read too slowly, bytes will be missed and a buffer underflow will ruin the transaction. Similarly, a transmission might fail if the single-byte transmission buffer isn't refilled quickly enough. I've also had trouble, for reasons that I can poorly explain, configuring the crystal oscillator through the debugging interface without shellcode.

As I described in my CC2430 Debugging Notes, the recommended method of flashing memory is to write a small block of code into XDATA RAM which does the actual write, then to branch to this code, waiting for a HALT (0xA5) opcode to return control to the debugger. This routine is provided in SWRA124 as machine code with assembly comments, beginning with the fragment shown below.


While this is fine and dandy for code that works, it's a bit infuriating to debug code in machine language. (Is that opcode supposed to be 0xA5 or 0xA6? Is the length of this instruction correct? Similar frustration abounds.) To correct for this, the GoodFET project now has a trunk/shellcode directory in addition to trunk/firmware and trunk/client. Shellcode is compiled for target microcontrollers, in this case just the CC1110 by SDCC, the Small Device C Compiler.

For example, this is the code that used to configure the crystal oscillator on the CC1110, a prerequisite for any radio operations:


That ugly mess becomes the following little fragment of C. It is compiled by 'sdcc --code-loc 0xF000 crystal.c' in order to place the code squarely within RAM, which is executable in this 8051 clone's unified memory architecture. (It's a Harvard chip that acts Von Neumann, or the other way around.)


For inputs to these functions, and also for their return values, I find it more convenient to declare arrays at known locations than to read the symbol files to find them. The syntax for placing an array in XDATA memory at 0xFE00 is 'char __xdata at 0xfe00 packet[256];'. You can find examples of this in txpacket.c and rxpacket.c in the GoodFET repository.

(3) Care to join the fun?

There are a number of features remaining to be implemented in shellcode. Among them in a completed port of Ossmann's $15 Spectrum Analyzer, which I began in CC1110 Instrumentation in Python and you can find in the contrib/ directory of the GoodFET repository. By dropping the GUI interface and replacing it with timing delays, full spectrum scans can be made in decent time without requiring that anything in flash memory be changed.

Another handy tool would be an OOK sniffer that over-samples, using the infinite-packet-length trick described in the CC1110 datasheet to fill ram with a recording. Triggering on RSSI allows the beginning of the packet to be reliably timed, with oversampling allowing for correction on all later bits. I've begun to implement this as 'goodfet.cc sniffook [freq]', but an enterprising neighbor should be able to start sniffing garage door remotes in short order.

A Morse-code library in combination with an external amplifier would also be neighborly for the licensed amateur bands. The ability of the microcontroller to quickly return and channel hop might be able to account for, among other things, the Doppler shift experienced in EME moon-bounce experiments, without losing backward compatibility with 19th century radio technology.

As a prize, I offer one ale apiece for GoodFET patches implementing these features.

Stay neighborly,
--Travis Goodspeed
<travis at radiantmachines.com>

CC1110 Instrumentation with Python

by Travis Goodspeed <travis at radiantmachines.com>
concerning the GirlTech IMME,
utilizing the GoodFET's Chipcon Debugger
to instrument Michael Ossmann's $16 Pocket Spectrum Analyzer.




Often a neighbor, such as myself, finds himself with a damned useful tool that's missing logging. Further, when this is a black-box application, it is undeniably inconvenient to patch in logging where no communications method exists. In this brief article, I will demonstrate how to instrument a Chipcon CC1110 application using Python and a GoodFET with zero bytes of modification to the original firmware image. My target's source code is available, but the technique applies just as well to black-box firmware.

Specifically, I want to dump the raw data from Michael Ossmann's $16 Pocket Spectrum Analyzer in order to demo it on stage at our Toorcon 12 talk, Real Men Carry Pink Pagers. I'll assume the reader to be familiar with Mike's article, as well as my article on wiring an IMME for debugging with a GoodFET. Readers wishing to play along can order a GoodFET31 for little or no money by following these instructions.

From the datasheet or Mike's Makefile it can be seen that the external RAM (XDATA, which is called external for historic reasons) section begins at 0xF000. The only structure at this location is xdata channel_info chan_table[NUM_CHANNELS], where NUM_CHANNELS is defined to be 132 and the channel_info struct is eight bytes, defined as

typedef struct {
 /* frequency setting */
 u8 freq2;
 u8 freq1;
 u8 freq0;
 
 /* frequency calibration */
 u8 fscal3;
 u8 fscal2;
 u8 fscal1;

 /* signal strength */
 u8 ss;
 u8 max;
} channel_info;

The first several entries in this struct might be as follows. The first of these lines defines the frequency to be 0x22af4b, the frequency calibration to be 0xef2c27, and the signal strength to be 0x41. The final byte defines the maximum strength, which is zero unless max-highlighting mode is turned on.

 22 af 4b ef 2c 27 41 00
 22 b1 43 ef 2c 27 3e 00
 22 b3 3b ef 2c 27 46 00
 22 b5 33 ef 2c 27 3c 00
 22 b7 2b ef 2c 27 44 00
 22 b9 23 ef 2c 28 3c 00
 22 bb 1b ef 2c 28 42 00
 22 bd 13 ef 2c 28 3f 00
 22 bf 0b ef 2c 28 3d 00
 22 c1 03 ef 2c 28 40 00
 22 c2 fb ef 2c 28 3d 00
 22 c4 f3 ef 2c 28 3e 00
 ...

This information can be extracted by halting and resuming the CPU, just as I did in my article on the PRNG Vulnerability of Z-Stack's ZigBee SEP ECC implementation. That is, GoodFETCC.CCpeekdatabyte() is used to grab these bytes from the CC1110's RAM. The following code dumped the fragment shown above.

#!/usr/bin/env python 

import sys;

sys.path.append('/Users/travis/svn/goodfet/trunk/client/')

from GoodFETCC import GoodFETCC;
from intelhex import IntelHex16bit, IntelHex;
import time;

client=GoodFETCC();
client.serInit();

client.setup();
client.start();

bytescount=8*132;
bytestart=0xf000;

while 1:
    time.sleep(1);
    client.CChaltcpu();
    
    dump="";
    for foo in range(0,bytescount):
        dump=("%s %02x" % (dump,client.CCpeekdatabyte(bytestart+foo)));
        if foo%8==7: dump=dump+"\n";
    print dump;
    sys.stdout.flush();
    client.CCreleasecpu();

To get proper data, it is necessary to add a wake-up delay of a few seconds, so that the table is populated by the first sampling. Additionally, it is handy to convert the frequency to MHz from its native unit (Hz/396.728515625). Finally, successive pages should be separated by a time column in order to facilitate graphing. The result is this script, which can be found in the GoodFET project as "contrib/ccspecantap/specantap.py".

An example recording can be seen below, as a spectrum recording of a friend's Kenwood FreeTalk UBZ-AL14 FM Transceiver unit. This is compatible with other family FM radios, and I wanted to know which center frequencies were in use. In the first image, I've highlighted the noise floor as blue and the peaks as green. In the second image, the time domain is used to show broadcasts on several channels in sequence, all of which fall into one of the two center frequencies: 925MHz and 935MHz. The raw data is here, best viewed with NASA's excellent Viewpoints tool.



Future additions to this project will include integration into the GoodFET radio framework, as well as a 2.4GHz version built around the CC2430 and CC2530. The performance of the tap can be greatly improved by using block transactions rather than peeking individual bytes, and the view can be re-tuned by poking the configuration IDATA variables, positions of which are described in specan.rst as produced by the SDCC compiler.

It's also handy to know that a Chipcon radio will halt if the 0xA5 opcode is executed. In this manner, patching a single byte of a while() loop can allow the state at every iteration to be dumped.

This technique of scripted debugging through a programmer can be handy for more than instrumentation. Unit tests can be run on an assembly line without additional wiring, and--by single-stepping--execution traces of unknown firmware can be generated for assisting in reverse engineering. Those with enough patience can use this to fuzz test embedded systems for security vulnerabilities.

For help instrumenting your own Chipcon or MSP430 project, join us in #goodfet on irc.freenode.net or send me an email. The project has advanced to the point where interesting things can be done from Python alone, and I'd quite like to see what could be done with it.

Smartgrid Skunkworks

Dearest engineers and hackers, and also their management,

Recent vulnerabilities found in smart meters and HAN devices have shown a number of weaknesses in the engineering practices used to build these devices and their constituent components. A vulnerability in a chip or library is fixed slowly, and it is a very rare event that the meter and thermostat vendors affected by the vulnerability are notified by their suppliers. Because of this, vulnerabilities are spreading downward through the supply chain, and the engineers of smart grid devices are left uninformed.

While those utilities that actively investigate security have a considerable amount of bargaining power with their immediate suppliers, the rest of the supply chain has no similar leverage to compel security notifications. Chip and library vendors are failing to notify the meter vendors that depend upon their components. Even when the meter vendors are notified directly of vulnerabilities, thermostat and other HAN vendors can have no realistic expectation of such a privilege.

Despite having found many vulnerabilities in microcontrollers and LPAN radio chips, I have never seen one single security issue mentioned in the errata sheets of these devices. It has been a year since I first reported to Texas Instruments that the RAM of their Chipcon 8051 core is exposed to an attacker, but there's not one scrap of documentation from the firm to its customers suggesting that they make the simple patch of moving the key variables to Flash memory. The example ZigBee stack for the chip is still vulnerable to this attack, even after recent patches! A year later, exactly two debugger commands are all that are required to extract keys from nearly every ZigBee SEP device with a Chipcon radio, and no one knows to patch their code! (Do not be smug if you are an Ember customer. The EM2xx chips are unpatchably vulnerable to debugger key extraction, and there is no mention of this in the chip's errata sheet either.)

As chip and library vendors have failed to document the publicly known vulnerabilities in their products, and as they have often been unable or unwilling to repair them, the most expedient remedy to this problem is a separate line of communication. At least one point of reference must exist for the engineers trying to build these products.

For these reasons, I have created a skunkworks mailing list for the announcement and discussion of smart grid vulnerabilities, particularly but not exclusively those in AMI equipment. This is to be a list for engineering discussion, by engineers and security researchers. Anonymous posts and lurking are welcome, but politics and committee items are not.

For this reason, I especially request that those firms which care about security ask--or perhaps even require--their engineering staff to subscribe. This list is the appropriate place to post questions concerning the secure use of a particular radio chip, fragment of code, or anything else which is too low level or vendor-specific to be mentioned in standards.

If your firm is unwilling to allow its engineers to post, please at least compel them to follow the posts of others. In saying nothing, they will still learn how to make more secure products along with all sorts of fascinating gossip about your competitors. Your firm has every right to keep its mouth shut, but keeping its ears shut is a betrayal of each and every one of your customers.

To kickstart this mailing list, I will make it my first site of public disclosure for smart grid vulnerabilities over the coming months. The subscription link is below, and I invite you to join me in preventing smart grid vulnerabilities before they are created.

http://groups.google.com/group/smartgrid-skunkworks

Thank you kindly,
--Travis Goodspeed
Belt Buckle Engineer
Security Hobbyist

IM ME GoodFET Wiring Tutorial

by Travis Goodspeed <travis at radiantmachines.com>

concerning the Girltech IM ME,

with a million thanks to Dave.



WARNING: Reflashing the CC1110 while batteries are low will permanently lock the chip. Either be damned sure to use fresh batteries or leave the batteries out and power the IMME from your GoodFET.



Howdy y'all,



This brief tutorial describes the process of reflashing the Girltech IM ME with custom firmware, so that it may be used as a development platform for the Chipcon CC1110 sub-GHz ISM System-on-Chip. I assume the reader to have an assembled GoodFET with recent firmware, but other programmers may of course be substituted.



You should also read Dave's first article on IM ME hacking, as it describes his method for reprogramming the device. All the pinouts below were taken from his articles, as well as the keyboard and LCD information that he was so neighborly as to publish.

Wiring

First, you'll need to purchase an IM ME, which can be had for $20 USD on a few toy sites while it remains in stock. You'll also need an assembled GoodFET and basic electronics tools.



The testpoints used for programming the IM ME are located behind the batteries in the rear compartment of the device. Ideally, a bed of nails should be used to clip into it, but failing that, just solder on to the Debug Data (DD), Debug Clock (DC), Reset (!RST), and GND pins. Run these to the GoodFET's 14-pin header as shown below.









From left to right on the IM ME, the pins are !RST, DD, DC, +2.5V, and Ground. Because the GoodFET is a low-voltage device, there's no need for the resistor dividers in Dave's article. Use EITHER the GoodFET OR the batteries for VCC, but not both.

Name	Pin		Name
DD	1	2	Vcc
	3	4	Vcc
RST	5	6
DC	7	8
GND	9	10
	11	12
	13	14

Flashing

Once you have the IM ME wired up, you can check its model number and status by running `goodfet.cc status'. This will tell you that the chip is locked, so making a backup of its firmware is non-trivial. If you continue from here, the IM ME will no longer function as an instant messenger.



Erase the chip by 'goodfet.cc erase' then dump an image of RAM as 'goodfet.cc dumpdata immeram.hex' to see if anything neighborly can be found inside.



You now have a blank IM ME, with the LCD most likely showing the last gasping breaths of its firmware. To flash a new firmware image, just grab its ihex file and run 'goodfet.cc flash foo.hex'.



I've placed a few example binaries in the repository of an operating system that I've started for the IM ME called GoodME. To flash Dave's LCD Test, run the following commands.

svn co https://goodfet.svn.sourceforge.net/svnroot/goodme

goodfet.cc flash goodme/bins/dave-lcdtest.hex



For a more functional demo, try bins/term-morse824mhz.hex, an ugly hack of an operating system for the IM ME with a Morse code transmitter and random number generator demo. In the Radio demo, holding any of the letter buttons broadcasts on 824MHz. The PRNG demo, shown below, demonstrates the repetition of strings withing the psuedo-random number generator and counts the number of bytes between them. This is sometimes used for key material.

Custom Development

The SDCC compiler is in the package repositories of most civilized operating systems. You might need a more recent version for the cc1110.h header, though building this compiler is a thousand times simpler than GCC. Compiling an example is as simple as sdcc foo.c; packihx <foo.ihx >foo.hex, which will produce a suitable Intel Hex file for flashing. The 8051 memory model makes specifying a chip model unnecessary, a handy deviation from those of us with a thousand MSP430 linking scripts.



Within the GoodME repository, you'll find my bastard child of an operating system at /branches/rough/. It was used to make the term-morse824mhz.hex, and its keyboard, font, and LCD drivers are ripe for organ transplants. /trunk/ ought to someday contain a proper operating system for the device, but for now, I haven't the time to complete it.



Have fun, and build something neighborly,

--Travis

XML of SmartRF Studio 7

by Travis Goodspeed <travis at radiantmachines.com>
concerning TI SmartRF Studio 7.

For those who have not personally suffered the experience, choosing radio register values is an absolute pain. In this brief article, I will demonstrate a method for extracting settings in bulk from SmartRF 7 Studio for use in other projects.

Suppose that a program should configure a CC1110 to operate on a particular frequency, in a particular encoding, etc. The code will like the following, which is from the CC1110 examples. This will generate a carrier wave near 823 MHz, as the 2.433GHz FREQ[] value is outside of the allowed range.



To choose a different center frequency, the engineer is expected to either find the register's definition within the datasheet or use SmartRF Studio, a screenshot of which is below. The software is a Windows application for communicating with a radio through a serial port. It also allows an engineer to load preconfigured profiles for certain types of modulation, such as IEEE 802.15.4 or SimpliciTI. Once loaded, the settings may be tweaked and loaded into a packet-sniffer firmware for debugging projects.



The screenshot above, from SmartRF 6, can provide a decent idea of how infuriating the software might become. For product development, the register settings are to be copied and pasted into opaque source files. It can instill the same sort of anger as an uncooperative web form, even after the old Visual Studio 6 libraries have been located to make it work under Wine.

SmartRF 7--at Beta 0.9.1 as of this writing--is a new client under active development, one which seems to have been rewritten from scratch or at least significantly refactored. The old Win32 GUI has been replaced with QT4, making a future Linux or Mac port possible. Most importantly of all, however, is that the default configurations, as well as register explanations, are stored as XML.



The screenshot above shows how default configurations are chosen for the target radio. Users can select an example, then change any of the settings they like. These configurations are further abstracted into an "Easy Mode" which hides all the messy minutia of radio, abstracting use to standards and channel numbers.

These configuration settings are to be found as XML in the config/xml/ directory, organized by chip and presentation. The following is an example of one such configuration file for the CC1110.


Patching these configurations allows for the easy addition of new standards. For example, I added support for my Tennessee Belt Buckle radio by adding a new stanza to easymode_settings.xml.


The register definitions and their bitfields are also defined in XML. The following from register_definition.xml for the CC1110 described the FREQ2 register's meaning.


Printing SDCC special-function register definitions, such as those found in cc1110.h, is as easy as a bit of Python magic,

#!/usr/bin/python

# Simple script for dumping Chipcon register definitions to SDCC header.
# Only intended as a rough example.
# by Travis Goodspeed, Engineer of Superior Belt Buckles

import xml.dom.minidom
def get_dom(chip="cc1110",doc="register_definition.xml"):
    fn="/opt/smartrf7/config/xml/%s/%s" % (chip,doc);
    return xml.dom.minidom.parse(fn)

dom=get_dom();

for e in dom.getElementsByTagName("registerdefinition"):
    for f in e.childNodes:
        if f.localName=="DeviceName":
            print "// %s=%s" % (f.localName,f.childNodes[0].nodeValue);
        elif f.localName=="Register":
            name="unknownreg";
            address="0xdead";
            description="";
            for g in f.childNodes:
                if g.localName=="Name":
                    name=g.childNodes[0].nodeValue;
                elif g.localName=="Address":
                    address=g.childNodes[0].nodeValue;
                elif g.localName=="Description":
                    if g.childNodes:
                        description=g.childNodes[0].nodeValue;
            print "SFRX(%10s, %s); /* %50s */" % (name,address, description);

These configuration files should allow for new Chipcon radio applications and development tools to be written in short order. Please contact me if you would be so kind as to write a complete Python class for querying this data.

ZStack PRNG Fixed

by Travis Goodspeed <travis at radiantmachines.com>
concerning versions 2.2.2 and 2.3.0 of TI Z-Stack
and a fix of the ZigBee Smart Energy Profile ECC vulnerability.

Texas Instruments has released version 2.3.0 of Z-Stack, their ZigBee stack for the TI/Chipcon CC2530, MSP430, and CC430 chips. The new version adds a variety of new features, but chief among them is a fix to the random number generator which used to be utterly insufficient for cryptographic use. Technical details on the vulnerability were first revealed publicly in my last article. (Nate Lawson's translation is here.)

Source code for the new generator is not included, but rather references as a Security Service Provider (SSP). Since 2.2.3, they have extended the SSP API to include SSP_GetTrueRandAES() for generating random numbers by an AES key.



This is then called in zclGeneral_KeyEstablishment_GetRandom(), which in previous versions used the 16-bit LFSR.



Authors of firmware for ZigBee Smart Energy devices that have used this code should patch their source code and issue firmware upgrades as quickly as possible. Those with independent crypto implementations should check to ensure that they have not made similar mistakes. Programmers should also note that

Electric utilities with equipment using the MSP430 or Chipcon CC2530 should contact their vendors for such updates. Unlike Windows and Linux, there's no easy way to perform an upgrade of a fragment of microcontroller firmware to which you haven't got the source.

This fix only applies to the remote recovery of keys by PRNG attacks; local key extraction is still possible by the methods that I outlined in Extracting Keys from Second Generation ZigBee Chips.

PRNG Vulnerability of Z-Stack ZigBee SEP ECC

by Travis Goodspeed <travis at radiantmachines.com>
with neighborly thanks to Nick DePetrillo,
concerning version 2.2.2-1.30 of TI Z-Stack
and a ZigBee Smart Energy Profile ECC vulnerability.



In past articles, I've presented a variety of local attacks against microcontrollers and ZigBee radios. While I maintain that local vulnerabilities are still very relevant to ZigBee devices, this article presents a remotely exploitable vulnerability in the way that random keys are generated by TI's Z-Stack ZCL implementation of the ZigBee Cluster Library. Randomly generated numbers--those fed into the Certicom ECC crypto library--are predictable, repeated in one of two 32kB cycles. Details follow, with links to source code and a complete list of random numbers.

Dumping Random Bytes

I dumped byte sequences from the CC2430 using the GoodFET to debug a live chip. The chip runs a program which populates IRAM with PRNG bytes, then halts with a soft breakpoint (Opcode 0xA5) for the debugger to grab all sampled values. The main loop looks something like this:

The firmware was compiled with the Small Device C Compiler, flashed by the GoodFET. A quick Python script then used the GoodFET library to debug the target, dumping random values through the same interface that programmed the chip.

Short PRNG Period

Page 18 of the CC2530 Datasheet describes the random number generator peripheral, which is shared by all other 8051-based ZigBee SoC devices in the series.
The random-number generator uses a 16-bit LFSR to generate pseudorandom numbers, which can be read by the CPU or used directly by the command strobe processor. The random numbers can, e.g., be used to generate random keys used for security.

The state of this RNG is initialized in the hardware abstraction library by feeding 32 bytes from the ADCTSTH special function register into RNDH register. Bytes read from ADCTSTH are physically random, but poorly distributed. RNDH and RNDL are the High and Low bytes of a 16-bit CRC Linear Feedback Shift Register, the state of which can be advanced by writing to RNDH or overwritten by writing to RNDL. In between reading or writing from RND, the state is advanced by setting the fourth bit of ADCCON1. Detailed descriptions of these registers can also be found within the datasheet.

CC2430 examples randomize the seed by mixing 32 values into the RNG,

for(i=0;i<32;i++){
    RNDH=ADCTSTH;
    ADCCON1|=0x04;
}

Because these numbers are not evenly distributed, Z-Stack prefers to sample just the least significant bit of the RF random number generator sixteen times, then write them in directly as the state without mixing them. Further, it checks to ensure that the state is not a dead-end, substituting another if it is. This method is also advocated within the CC2530 programming guides.

for(i=0; i<16; i++)
      rndSeed = (rndSeed << 1) | (RFRND & 0x01);
if (rndSeed == 0x0000 || rndSeed == 0x0380)
      rndSeed = 0xBABE;
RNDL = rndSeed & 0xFF;
RNDL = rndSeed >> 8;

Once the RNG has been seeded, it has an initially random 16-bit state. From then on, however, it produces random bytes in a predictable sequence. Only the starting point is random, as ADCTSTH is never used for future reseeding. As shown in the screenshot above, if the sequence "7c e1 e8 4e f4 87" is observed, the probability of the next bytes being "62 49 56 fe 80 00 60" is 100 percent. Further, because the domain is so small, it can be exhaustively searched for keys in little time.



Code for dumping these values through the GoodFET debugger can be found by svn, along with a complete dump of the PRNG sequence.
svn co https://goodfet.svn.sourceforge.net/svnroot/goodfet/contrib/ccrandtest

Seed Values

The plot above shows the histogram of radio ADCTSTL values used to seed the PRNG. These are far from random, but when sampled slowly enough, their least significant bit is probably good enough for key generation. There are, however, two things of interest with this.

First, if the crypto library is used infrequently, it would make sense to use this source of entropy instead of the inadequately random PRNG output. There would be a cost in power consumption, as ADCTSTL is only random while the radio is operating, but the resulting increase to security is necessary.

Second, if the peaks on the histogram come from a measurement of the radio, it might be possible to generate a radio signal that forces even the least significant bit to be a predictable value. Steps such as AES whitening should be taken to avoid such an attack.

ZigBee SEP, ECC

A less than perfect random number generator is not much of an issue when symmetric keys are pre-shared, but because pre-shared keys are vulnerable to local attacks, the ZigBee Smart Energy profile recommends the use of session keys signed by elliptic curve cryptography. See the USAF paper Cryptanalysis of an elliptic curve cryptosystem for wireless sensor networks for a prior break of ECC with a poor RNG.

As will be shown in the next section, Chipcon's ZStack makes use of poorly random PRNG data as key material, allowing for a key domain of only 16 bits. This is small enough to be exhaustively searched, either by a PC or by a "Chinese Lottery" of previously compromised wireless sensors.

ZStack Usage

ZStack 2.2.2-1.30 for the CC2530 makes use of the PRNG to implement the Smart Energy Profile's asymmetric cryptography. The Windows installer works perfectly under Wine, leaving ZStack installed to an awkward directory. I symlink it to /opt/zstack for convenience.


Once installed, the following Functions are of interest.

mac_mcu.c contains macMcuRandomByte() and macMcuRandomWord(). As the two are largely the same, take the former for an example. First the PRNG is clocked, then the high byte is sampled.


zcl_key_establish.c is used to generate keys by the ZigBee Cluster Library specification, available for free by form from ZigBee.org. The code fragment below takes the low bytes of macMcuRandomWord(), redefined as osal_rand(), to populate a session key before signature.


The ultimate function for ECC key generation is ZSE_ECCGenerateKey(), which is defined in eccapi.h but whose source is missing. Reading ecc.r51 yields a few filenames as part of stored compiler warnings. The developer's filename was "C:\SVN-ZStack-2.2.0\Components\stack\sec\eccapi.c", but it is only a stand-in for the Certicom Security Builder MCE library that is not shipped with the development kit. In any case, the vulnerability here lies in ZStack and not in Security Builder.

Conclusions

This article has shown that the Chipcon ZStack library, as of version 2.2.2-1.30 for CC2530, uses an insufficiently random PRNG for cryptographic signatures and session keys. PRNG data repeat every 32,767 samples, and there are at most 16 bits of entropy in any key. Searching the entire key space ought to be possible in very little time. Contrary to the CC2530's documentation, these random numbers must not be used to generate random keys used for security.

All users of this library, particularly those using it for Smart Grid devices and other industrial applications, are recommended to re-implement macMcuRandomWord() and to ensure that nothing requiring cryptographic security operates from the PRNG alone. Users of other libraries for the Chipcon devices should ensure that those libraries are not using the PRNG data.

Competing devices and libraries should also be checked for similar vulnerabilities, as well as commercial products such as Smart Meters that might have forked the ZStack code or followed the datasheet's recommendation of using the PRNG for key generation.