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