S4 Paper

Howdy Y'all,

A paper of mine from S4/Miami, Low-Level Design Vulnerabilties in Wireless Control Systems Hardware, has recently been made publicly available by Digital Bond. Coauthored with Brad Singletary and Darren Highfill, it provides a detailed survey of vulnerabilities that might be found in the hardware and firmware of AMI Smart Meters and similar equipment.

Please note that the paper, written late last year, is now outdated in two respects. First, the self-propagating worm presented hypothetically in Section 3.1 is no longer hypothetical. Mike Davis has written one. Second, the System-on-Chip Zigbee devices advocated in the conclusion of Section 4.1 are not secure, as I have since demonstrated in Extracting Keys from Second Generation Zigbee Chips.

--Travis Goodspeed
<travis at radiantmachines.com>

Speaking at 25C3

At the 25th Chaos Communications Congress in Berlin this December, I'll be presenting some new research in the security of the MSP430's serial bootstrap loader (BSL) as well as a nice little lecture/workshop combo on reverse-engineering the TI EZ430 development tool.

I intend to travel through France and England, returning in late January for S4, Miami. Please email me if you'd like to meet.

Cracking the MSP430 BSL
Day 1 (2008-12-27), 20h30 (8:30 pm) in Saal 3.

The Texas Instruments MSP430 low-power microcontroller is used in many medical, industrial, and consumer devices. When its JTAG fuse is blown, the device's firmware is kept private only a serial bootstrap loader (BSL), certain revisions of which are vulnerable to a side-channel timing analysis attack. This talk continues that from Black Hat USA by describing the speaker's adventures in creating a hardware device for exploiting this vulnerability.

While the previous part focused on the discovery of the timing vulnerability and its origin, this lecture will focus on the exploitation. Topics include a brief review of the vulnerability itself, PCB design and fabrication, the malicious stretching of timing in a bit-banged serial port, observation of timing differences on the order of a microsecond, and the hell of debugging such a device.

Repurposing the TI EZ430U
Lecture: Day 3 (2008-12-29), 12h45 (pm) in Saal 3
Workshop: Not yet scheduled.

USB devices are sometimes composed of little more than a microcontroller and a USB device controller. This lecture describes how to reprogram one such device, greatly expanding its potential.

At only twenty dollars, the Texas Instruments EZ430U is a bargain of an in-circuit debugger for the MSP430 microcontroller. The board itself is composed of little more than an MSP430 and a USB to Serial controller. The board's JTAG fuse is unblown, and full schematics are included in public documentation. This lecture will discuss the use of the EZ430U, not as a debugging tool, but as a development platform in and of itself. Topics will include the writing of replacement firmware, analysis of the default firmware, reprogramming the USB to Serial controller, and potential target applications.

--
Travis Goodspeed
<travis at radiantmachines.com>

Speaking at PumpCon 2008 in Philly

Howdy Y'all,

I'll be driving to Philadelphia on Friday, October 24th to speak at this year's PumpCon. This lecture continues that of Black Hat USA, focusing on the exploitation--rather than the origin--of timing vulnerabilities that I've found in certain revisions of the MSP430's serial bootstrap loader.

--Travis Goodspeed
<travis at utk.edu>

MSP430 Side-Channel Timing Attacks, Part 1

by Travis Goodspeed <travis at utk.edu>
at the Extreme Measurement Communications Center
of the Oak Ridge National Laboratory

regarding ongoing work performed in collaboration with
David Carne <davidcarne at gmail.com>

What follows is a brief introduction to microcontroller side-channel timing attacks, as one might find them on the MSP430 microcontroller. This sort of attack is most commonly used against cryptography, but my present discussion will focus on attacking password-comparison routines. Be sure to check your own code--as well as that of your library vendors--for this issue.

Suppose that a password protection routine accepts a password through the serial port from an untrusted source, compares the password, and raises the privilege level if the password is correct. We will consider the following attempts at implementing such protection.

strcmp

Using strcmp() is clearly not a secure option, because it leaks information. Let us consider the implementation from the strcmp article at Wikipedia.

int strcmp (const char * s1, const char * s2){
   while ( *s1 == *s2 && *s1 != '\0' ) {
        s1++;
        s2++;
   }
   return *s1 - *s2;
}

This function--when used to compare passwords--runs in linear time, which is to say that every correct letter of the password adds a constant amount of time to the function's execution. By measuring the time that it takes to return, an attacker can guess the password one byte at a time. So an attacker could guess a 32-byte password in at most 32*256=8192 attempts, instead of the 2^^(8*32) attempts that might naively be assumed.

Another Attempt

Aversion to the C string comparison function is often enough to prompt authors to come up with creative comparison methods. One vendor uses a scheme similar to the following:

• An access control variable is set to 1.
• For each input byte:
  • The input byte is compared to the matching byte of the password.
  • If the two differ, the access control variable is cleared.
• Access is granted if the access control register is still set.

The center of this loop, if isolated to be a function, looks something like this:

void check(char a, char b){
  if(a!=b)
    access=0;
}

When compiled to assembly language with GCC, the result is the following:

    c040:       4d 4f           mov.b   r15,    r13     ;
    c042:       4d 9e           cmp.b   r14,    r13     ;
    c044:       02 24           jz      $+6             ;abs 0xc04a
    c046:       82 43 22 02     mov     #0,     &0x0222 ;r3 As==00
    c04a:       30 41           ret

Which has the following flow diagram:

Even though the password comparison is now independent of length, there is a still a variance in timing. Every incorrect byte of the password will add four cycles of execution time to the comparison! To fix this, it's necessary to make an else{} clause which balances the timing.

In practice, it's often only possible to determine whether a guess regarding timing is correct or incorrect. This is done by "gambling a clock edge", using non-standard timing in a serial protocol such that an edge is detected under one timing but not detected in another. Using this technique, the worst-case time for guessing is the same as the strcpy() example.

The possibility remains, however, that still more information may be leaked. In such a case, because all bytes are compared, it might be possible to break the password in significantly fewer attempts. The fastest cracking case would be one in which each byte's correctness could be individually determined, in which case the password could be guessed in 256 attempts.

Balanced Timing

A proper password comparison ought to look like the following, which takes the same amount of time to execute, regardless of the password's correctness.

Proper support for automated timing analysis isn't yet available in msp430static, but its insflow() sub--which was used to generate the diagrams above--does a lot of the work. To reproduce these diagrams, dump the flow graph to disk then annotate timing to match the Instruction Timing section of the mspgcc manual or the Instruction Cycles and Lengths subsection of the Instruction Set section of an MSP430 family guide. The Single Line MSP430 Assembler is also handy.

I'll be writing more on this topic in the near future, perhaps citing some examples of this vulnerability that I've located in the wild.