Category: Hardware

DIY USB to TTL serial adapter

~ Nate Lawson ~ 4 Comments

When people ask about my day job, I tell them it is “designing/reviewing embedded security and cryptography”.  I haven’t written much on this blog about my embedded work, mostly due to NDAs.  However, I recently have been working on some hobby projects in my spare time that are a good topic for some articles.

When interfacing with an external board over USB, it’s often easiest to use a USB-serial cable like the FTDI 232R.  This cable provides a virtual serial port interface to the PC host and the normal serial signals at the target.  You can then interact with your target using an ordinary terminal program.  One key difference is that the signals are LVTTL (0 – 3.3V) or TTL (0 – 5V), while ordinary serial is -10V to +10V.  So you can’t just use an ordinary USB-serial adapter, the kind used to connect an old PDA to your computer.

On a recent project, I needed to debug some code running in a microcontroller.  Since most microcontrollers these days have a built-in UART, debug prints can be added by configuring the clock divider for the given baud rate and monitoring a single pin (the RX pin).  With AVR libc, it’s as simple as providing a “send byte” routine to a local copy of stdout, then calling printf() as usual.  As I dug through my parts bin, I realized I didn’t have one of these FTDI cables and it was too late to buy anything.

My first thought was to use one of my scope probes to capture the serial I/O and decode it in software.  You can dump an oscilloscope’s trace buffer to a file, then walk through the samples for your given channel and recover the original data.  I decided this would take too long though, so I got a second opinion from bunnie.  I was hoping to scavenge one of the many ordinary USB-serial adapters I had lying around.  He told me that most of them are built with a separate level converter IC, so it was likely I could mod one to get what I wanted.

That was the motivation I needed to tear into an adapter.  It was covered with injection-molded plastic, so I had to use a knife to slice the edges and peel it back.  Inside, I found it had a FTDI 232BL, Sipe SP213ECA, and Atmel 93C46.  I think the Atmel is a serial EEPROM (8-pin, SOIC). If you search for the “Sipe” part, you will see a bunch of Chinese “part number squatters”.  That’s usually the tell-tale sign that a part isn’t sold via retail and is only used by OEMs as a clone.  I think the copied manufacturer is “Sipex”, so I used that datasheet. The FTDI chip is quite common and does all the logic for the USB and serial protocols.

The Sipex chip is a level converter, similar to the MAX232.  It uses a series of capacitors in a configuration called a “charge pump” to step the voltage up or down to +/-10V, while requiring only a 3.3V source of power.

My plan was to bypass the level shifter and connect my TX, RX, and GND pins directly from my microcontroller to the FTDI chip since both run at 3.3V.  However, I needed to disconnect the RX stage of the level shifter from the FTDI, otherwise there could be contention if my microcontroller was driving logic low and the FTDI was driving high.  I looked at the Sipe datasheet and did some investigation with my multimeter.  It turns out that the RX signal comes in from the serial port on pin 23 and goes out at the reduced TTL level on pin 22.

I could have cut pin 22 with a knife but that is hard to reverse if I wanted to put it back.  Instead, I used my soldering iron to release the pin and gently pry up on it.  This is called lifting a pin and is often done by techs doing rework.  I find it works best to nudge the pin sidewise with tweezers while heating it, then lift it.  You can lift a pin just a little if you only want to disconnect it, or you can lift it and bend it back over the package like I did if you plan to solder wire onto the pin and the pad.  I left it this way in case I wanted to add a switch in the future, allowing the same device to be used as a TTL or ordinary serial port.  (The ugly junk around the pins and under the chip is leftover plastic from the cover, a side-effect of the injection molding process.)

Next, I soldered ground, RX, and TX wires from the FTDI chip to a pin header.  I find it works best to put a little extra solder on the pins/pads and then apply heat above the wire until it melts into the solder on top of the pin.  Below is a picture of the header and the three wires.  The header isn’t connected to the serial port below, it’s actually floating above it.

Finally, I used a glob of hot glue to stabilize and insulate the header from the other connections on the chip as below.

I tested for shorts between pins and between Vcc and ground (very important).  It seemed fine so I plugged it in.  I needed a cable to match the pinouts of my microcontroller and the USB-serial adapter, so I took an old ribbon cable and swapped some of the wires around to match.  I find ribbon cables are really useful for building custom cables quickly since the tabs on the connectors come apart easily with a screwdriver and it presses back together once you’re done.  Below is the final result, about 45 minutes of work.

By the way, if you need an overview of the basics, here is an excellent intro to surface-mount soldering.  I especially agree with its complaint against the “flood and wick” style of SMT soldering.  I hope this article encourages you to find creative solutions to your interfacing problems.

Quantum cryptography is useless

~ Nate Lawson ~ 5 Comments

Bruce Schneier is right on the money with this article criticizing quantum crypto.  Quantum cryptography (not quantum computing) is one of those concepts that appeals to the public and the more theoretically-minded, but is next to useless for providing actual security.  Here are some less-known problems with it that I haven’t seen discussed much elsewhere.

Quantum cryptography is focused on one narrow aspect of security: key establishment.  To put it simply, this involves exchanging photons with a particular polarization.  The transmitter randomly sets their polarizer to one angle or the other and sends a photon.  The receiver also tunes their detector to a particular polarization.  The measured value at the receiver is dependent both on the sending and receiving polarizer states, as well as the bit transmitted.  The sender and receiver repeat this process many times in both directions to get a set of bits.  Some will be errors and some will be usable as a key, shared between both but secret.

To receive a photon, an attacker also has to choose a polarization.  By measuring the photon, the state of the attacker’s polarizer is encoded in the photon.  This means that the attacker cannot learn the bits without desynchronizing the sender and receiver.  If the error rate is too high, an attacker is present (or the fibre is bad).

There are a number of well-known issues with quantum crypto.  This key exchange process requires a reliable, non-influencable source of random bits at both the sender and receiver.  Also, there needs to be some kind of pre-existing shared secret between both parties to authenticate themselves.  The only way to do this is through classic crypto (e.g., public key).  Otherwise, the attacker could just splice a receiver and transmitter into the cable and perform a standard MITM attack.  Finally, the actual communication between the two parties is encrypted with a traditional cipher like AES, using the shared key.

I think this alone is enough to undermine the case for quantum crypto.  If you are convinced to spend lots of money and effort to replace classical crypto for the sole purpose of key exchange, shouldn’t standard crypto be considered unreliable for authentication and bulk encryption also?  This is Bruce’s point and is based on simple threat analysis.

Recently, this paper was published describing how bright flashes of light could temporarily overwhelm the detector circuit, allowing an attacker to trick the receiver into accepting bits as unmodified.  The receiver has multiple detectors, each with a different polarization.  Normally, only a photon with the proper polarization triggers the corresponding detector.  But a bright pulse at a particular frequency can temporarily blind multiple detectors, leaving the remaining one to trigger on a subsequent pulse.  By varying the frequency of the bright pulse to select individual detectors, the attacker can manipulate the receiver into thinking the originally transmitted bits are being received correctly.

This is a clever attack because it is based on unstated assumptions.  Quantum crypto doesn’t specify how a perfect detector circuit can be designed.  That’s just a black box.  The designers assume that individual photons can go into the black box and be measured securely.  But it’s not a black box, it’s a real world circuit that depends on optoelectronics and has associated limitations.

You can draw an analogy here to side channel or differential fault analysis.  The AES algorithm might be considered computationally secure, but there are many underlying assumptions in a real-world system that implements it.  There has to be a computer running the algorithm.  It may be realized in hardware or software.  It requires memory (DRAM, disk, core, tape?) to store intermediate state.  It takes up physical space somewhere.  It gets its input over some kind of busses.  The environment may be hostile, with varying voltage, heat, clock frequency, etc.

What other attacks could there be?  Is it possible to determine which polarizer was selected in the transmitter by probing it with light while it is preparing to send the photon?  Does it consume more current when switching from one state to another?  Are there timing variations in the transmitted photons based on whether the polarizer switched state or not?

Classical crypto implementations have been continually hardened in response to these kinds of attacks.  I think the perceived theoretical invulnerability of quantum crypto has resulted in less attention to preventing side channel or fault analysis attacks.  In this sense, quantum crypto systems are less secure than those based on classical crypto.  Given its cost and narrow focus on strengthening only key exchange, I can’t see any reason for using quantum crypto.

Xbox 360 security talk

~ Nate Lawson

This recent video of Michael Steil and Felix Domke talking about the Xbox 360 security scheme is the best overview I’ve seen so far.

Michael previously gave a nice talk summarizing the security flaws in the original Xbox.

The CPU itself supports hashing and/or encryption of physical pages, based on flags set in the upper word of the 64-bit virtual address.  They talk about how Felix was able to leapfrog off shader-based DMA to write to an unencrypted register save state structure, jumping through a syscall gate (sorta like return-to-libc) that was improperly validated by the hypervisor.  The end result was arbitrary code execution in the context of the hypervisor.  Quite impressive.

I’ve always wondered how different security features like encrypted RAM that have long been present in smart cards would take to “trickle-up” to the more complex platforms like game consoles.  While the Xbox 360 security is much better than the original Xbox, it seems like the big-systems people are reinventing techniques already tested and worked out in the microcontroller world.

For example, the 360 was vulnerable to a timing attack, where an internal secret key can be guessed by timing how long it takes to validate the submitter’s HMAC.  I’d be extremely surprised if any mainstream smart card were vulnerable to such a well-known legacy bug.

I have yet to see anyone publish information about applying power or RF-based side channel analysis to a game console, despite smart cards adding countermeasures to these almost 10 years ago.  Even earlier attacks on encrypted RAM have still not been attempted on modern systems.

These attacks probably haven’t been needed yet since software bugs were still present. However, the push by game consoles and cellphone manufacturers to increase their resistance to software attacks means it won’t be long before side-channel resistance becomes a must-have feature.  It will be interesting to see how long it takes big-system manufacturers to add countermeasures and whether they’ll choose to learn from the hard lessons we have seen in the smart card world.

Chris Tarnovsky demos smart card hacking

~ Nate Lawson

Chris Tarnovsky spoke to Wired and demonstrated his smart card hacking techniques. Chris became famous for hacking Echostar cards, which resulted in a multi-billion dollar lawsuit against News Corp. The trial ended in a pretty big win for DirecTV smart card supplier NDS, with the jury only finding them guilty of trying out a packaged attack that converted a DirecTV smart card to decrypt Dish Network video. The penalty for this? A whopping $46.95 (i.e., one month’s subscription fee) plus statutory damages.

In the video, Chris demonstrates some interesting techniques. It shows him decapsulating an ST16 CPU made by ST Micro from an IBM Java card. Then, he uses nail polish to mask the die and rust remover (i.e., hydrofluoric acid) to etch away the top metal layer of protective mesh to get at the CPU’s bus. He then uses a sewing needle to tap each line of the 8-bit bus in turn and then reassemble the data in software. He could just have easily driven the lines, allowing him to change instructions or data at will.

This attack is pretty amazing. It is simple in that it does not require an expensive FIB or other rework tools. Instead, a microscope and careful work with some household chemicals is all it takes. While the ST16 is a bit old, it was used in Echostar, hence the relevance of Chris’s demonstration. It will be interesting to see what happens next in the evolving capabilities for home-based silicon analysis.

Warning signs you need a crypto review

~ Nate Lawson ~ 4 Comments

At the RSA Conference, attendees were given a SanDisk Cruzer Enterprise flash drive. I decided to look up the user manual and see what I could find before opening up the part itself. The manual appears to be an attempt at describing its technical security aspects without giving away too much of the design. Unfortunately, it seems more targeted at buzzword compliance and leaves out some answers critical to determining how secure its encryption is.

There are some good things to see in the documentation. It uses AES and SHA-1 instead of keeping quiet about some proprietary algorithm. It appears to actually encrypt the data (instead of hiding it in a partition that can be made accessible with a few software commands). However, there are also a few troublesome items that are a good example of signs more in-depth review is needed.

1. Defines new acronyms not used by cryptographers

Figure 2 is titled “TDEA Electronic Code Book (TECB) Mode”. I had to scratch my head for a while. TDEA is another term for Triple DES, an older NIST encryption standard. But this documentation said it uses AES, which is the replacement for DES. Either the original design used DES and they moved to AES, or someone got their terms mixed up and confused a cipher name for a mode of operation. Either way, “TECB” is meaningless.

2. Uses ECB for bulk encryption

Assuming they do use AES-ECB, that’s nothing to be proud of. ECB involves encrypting a cipher-sized block at a time. This results in a “spreading” of data by the cipher block size. However, patterns are still visible since every 16-byte pattern that is the same will also encrypt to the same ciphertext.

All flash memory is accessed in pages much bigger than the block size of AES. Flash page sizes are typically 1024 bytes or more versus AES’s 16-byte blocksize. So there’s no reason to only encrypt in 16-byte units. Instead, a cipher mode like CBC where all the blocks in the page are chained together would be more secure. A good review would probably recommend that, along with careful analysis of how to generate the IV, supply integrity protection, etc.

3. Key management not defined

The device “implements a SHA-1 hash function as part of access control and creation of a symmetric encryption key”. It also “implements a hardware Random Number Generator”.

Neither of these statements is sufficient to understand how the bulk encryption key is derived. Is it a single hash iteration of the password? Then it is more open to dictionary attacks. Passphrases longer than the input size would also be less secure since the second half of the password might be hashed by itself. This is the same attack that was usable against Microsoft LANMAN hashes but that scheme was designed in the late 1980’s, not 2007.

4. No statements about tamper resistance, side channels, etc.

For all its faults, the smart card industry has been hardening chips against determined attackers for many years now. I have higher hopes for an ASIC design that originated in the satellite TV or EMV world where real money is at stake than in complex system-on-chip designs. They just have a different pedigree. Some day, SoC designs may have weathered their own dark night of the soul, but until then, they tend to be easy prey for Christopher Tarnovsky.

Finally, I popped open the case (glued, no epoxy) to analyze it. Inside are the flash chips and a single system-on-chip that contains the ARM CPU, RAM, USB, and flash controller. It would be interesting to examine the test points for JTAG, decap it, etc.

Knowing only what I’ve found so far, I would be uncomfortable recommending such a device to my clients. There are many signs that an independent review would yield a report better suited to understanding the security architecture and even lead to fixing various questionable design choices.

Apple iPhone bootloader attack

~ Nate Lawson ~ 7 Comments

News and details of the first iPhone bootloader hack appeared today. My analysis of the publicly-available details released by the iPhone Dev Team is that this has nothing to do with a possible new version of the iPhone, contrary to Slashdot. It involves exploiting low-level software, not the new SDK. It is a good example how systems built from a series of links in a chain are brittle. Small modifications (in this case, a patch of a few bytes) can compromise this kind of design, and it’s hard to verify that all links have no such flaws.

A brief disclaimer: I don’t own an iPhone nor have I seen all the details of the attack. So my summary may be incomplete, although the basic principles should be applicable. My analysis is also completely based on published details, so I apologize for any inaccuracies.

For those who are new to the iPhone architecture, here’s a brief recap of what hackers have found and published. The iPhone has two CPUs of interest, the main ARM11 applications processor and an Infineon GSM processor. Most hacks up until now have involved compromising applications running on the main CPU to load code (aka “jailbreak”). Then, using that vantage point, the attacker will run a flash utility (say, “bbupdater”) to patch the GSM CPU to ignore the type of SIM installed and unlock the phone to run on other networks.

As holes have been found in the usermode application software, Apple has released firmware updates that patch them. This latest attack is a pretty big advance in that now a software attack can fully compromise the bootloader, which provides lower-level control and may be harder to patch.

The iPhone boot sequence, according to public docs, is as follows. The ARM CPU begins executing a secure bootloader (probably in ROM) on power-up. It then starts a low-level bootloader (“LLB”), which then runs the main bootloader, “iBoot”. The iBoot loader starts the OSX kernel, which then launches the familiar Unix usermode environment. This appears to be a traditional chain-of-trust model, where each element verifies the next element is trusted and then launches it.

Once one link of this chain is compromised, it can fully control all the links that follow it. Additionally, since developers may assume all links of the chain are trusted, they may not protect upstream elements from potentially malicious downstream ones. For example, the secure bootloader might not protect against malicious input from iBoot if part or all of it remains active after iBoot is launched.

This new attack takes advantage of two properties of the bootloader system. The first is that NOR flash is trusted implicitly. The other is that there appears to be an unauthenticated system for patching the secure bootloader.

There are two kinds of flash in the iPhone: NOR and NAND. Each has different properties useful to embedded designers. NOR flash is byte-addressable and thus can be directly executed. However, it is more costly and so usually much smaller than NAND. NAND flash must be accessed via a complicated series of steps and only in page-size chunks. However, it is much cheaper to manufacture in bulk, and so is used as the 4 or 8 GB main storage in the iPhone. The NOR flash is apparently used as a kind of cache for applications.

The first problem is that software in the NOR flash is apparently unsigned. In fact, the associated signature is discarded as verified software is written to flash. So if an attacker can get access to the flash chip pins, he can just store unsigned applications there directly. However, this requires opening up the iPhone and so a software-only attack is more desirable. If there is some way to get an unsigned application copied to NOR flash, then it is indistinguishable from a properly verified app and will be run by trusted software.

The second problem is that there is a way to patch parts of the secure bootloader before iBoot uses them. It seems that the secure bootloader acts as a library for iBoot, providing an API for verifying signatures on applications. During initialization, iBoot copies the secure bootloader to RAM and then performs a series of fix-ups for function pointers that redirect back into iBoot itself. This is a standard procedure for embedded systems that work with different versions of software. Just like in Windows when imports in a PE header are rebased, iBoot has a table of offsets and byte patches it applies to the secure bootloader before calling it. This allows a single version of the secure bootloader in ROM to be used with ever-changing iBoot revisions since iBoot has the intelligence to “fix up” the library before using it.

The hackers have taken advantage of this table to add their own patches. In this case, the patch is to disable the “is RSA signature correct?” portion of the code in the bootloader library after it’s been copied to RAM. This means that the function will now always return OK, no matter what the signature actually is.

There are a number of ways this attack could have been prevented. The first is to use a mesh-based design instead of a chain with a long series of links. This would be a major paradigm shift, but additional upstream and downstream integrity checks could have found that the secure bootloader had been modified and was thus untrustworthy. This would also catch attackers if they used other means to modify the bootloader execution, say by glitching the CPU as it executed.

A simpler patch would be to include self-tests to be sure everything is working. For example, checking a random, known-bad signature at various times during execution would reveal that the signature verification routine had been modified. This would create multiple points that would need to be found and patched out by an attacker, reducing the likelihood that a single, well-located glitch is sufficient to bypass signature checking. This is another concrete example of applying mesh principles to security design.

Hackers are claiming there’s little or nothing Apple can do to counter this attack. It will be interesting to watch this as it develops and see if Apple comes up with a clever response.

Finally, if you find this kind of thing fascinating, be sure to come to my talk “Designing and Attacking DRM” at RSA 2008. I’ll be there all week so make sure to say “hi” if you will be also.