root labs rdist

April 30, 2008

History of TEMPEST and side channel attacks

Filed under: Crypto,Embedded,Security — Nate Lawson @ 5:11 pm

A very interesting paper, “TEMPEST: A Signal Problem“, was recently declassified by the NSA. It gives a short history of TEMPEST and other side channel attacks, that is ways to discover a secret cryptographic key by monitoring indirect channels like RF emissions, sound, or power. Besides the new information that TEMPEST was discovered by Bell Labs in 1943, there are a number of lessons to learn from this paper.

It’s interesting that RF emissions in the form of oscilloscope perturbation were the first side channel found. After that, the paper covers acoustical, power line, seismics, and flooding. The last two are uncertain since the body of the text is still classified. In modern terminology, the attacks were SPA (simple side-channel analysis) since the plaintext was read directly from distinct “fingerprints” that appeared on the scope. DPA (differential side-channel analysis) involves more complex acquisition and statistical correlation of multiple samples, something this paper does not reveal as known at the time.

The history of attempted countermeasures is a good case study. First, Bell Labs tried to produce a heavily-shielded cipher machine. The army would not purchase it because it wasn’t a simple retrofit to the existing model. The final recommendation was that field personnel control a zone 200 feet in diameter from all cipher machines. There was no study that showed this was the perfect range, only that most field offices could do this without difficulty and it probably helped. This is very similar to countermeasures today, where cost or deployment effort are often more important than achieving the best security.

The categories of countermeasure they identified were:

  • Shielding/filtering: reducing the signal strength of emissions
  • Masking: adding random noise to the environment

If you think of a side channel attack as a communications problem, it’s obvious this is the classic signal-to-noise ratio. The paper states that they had trouble effectively shielding devices and that masking wasn’t effective either. This fits with the environment today, where addressing side-channel leakage in a modern embedded system is extremely difficult.

As power consumption decreases naturally with shrinking hardware, things improve but similar increases in the sensitivity of monitoring equipment improve as well. Also, processors and FPGAs get faster every day, allowing for more complicated signal processing. As the paper concluded in 1972, side-channel attacks today tend to lead countermeasure sophistication. If you’re concerned about such attacks, be sure to get your design reviewed.

April 21, 2008

Do fuzzed bugs look different?

Filed under: Security — Nate Lawson @ 3:50 pm

During a conversation with Thomas Ptacek about bug-hunting techniques, I came up with an interesting question.  Do patches for bugs found through fuzzing or other automated techniques look any different than those found manually?  Of course, the bugs themselves will likely be similar but will the patches also have some signature?

I have a hunch that bugs found via fuzzing show up in the perimeter of code, whereas those found manually may be deeper down the callstack.  Or, they may usually be the same class of header-based integer overflow, fixed by similar range checks.

Can anyone who has more experience in this area enlighten me?  Halvar and Ero, got some neat bindiff stats to show?

April 11, 2008

Designing and Attacking DRM talk slides

Filed under: Crypto,Hacking,Security,Software protection — Nate Lawson @ 4:18 pm

I gave a talk this morning at RSA 2008 on “Designing and Attacking DRM” (pdf of slides). It was pretty wide-ranging, covering everything from how to design good DRM to the latest comparison of Blu-ray protection, AACS vs. BD+. Those interested in the latter should see the last few slides, especially with news that AACS MKBv7 (appearing on retail discs later this month) has already been broken by Slysoft.

The timeline slide (page 25) is an attempt to capture the history of when discs were released into an unbroken environment or not. You want the line to be mostly green, with a few brief red segments here and there. AACS so far has had the inverse, where it is a long red line with a brief segment of green (a couple weeks in the past year and a half).

I also introduced two variables for characterizing the long-term success of a DRM system, L and T. That is, how long each update survives before being hacked (L), and how frequently updates appear (T).

In the case of AACS, L has been extremely short (if you discard the initial 8-month adoption period). Out of three updates, two have been broken before they were widely-available and one was broken a few weeks after release.

Additionally, T has been extremely long for AACS. Throwing out the initial year it took to get the first MKB update (v3), they’ve been following an approximate schedule of one every 6 months. That is much too long in a software player environment. I don’t know any vendor of a popular win32 game that would expect it to remain uncracked for 6 months, for example.

Of course, people in glass houses should not throw rocks. As someone who had a part in developing BD+, I am biased toward thinking a different approach than mere broadcast encryption is the only thing that has a chance of success in this rough world. The first BD+ discs were cracked in mid-March, and it remains to be seen how effective future updates will be. Unfortunately, I can’t comment on any details here. We’ll just have to watch and see how things work out the rest of this year.

2008 will prove whether a widely deployed scheme based on software protection is ultimately better or equivalent to the AACS approach. I have a high degree of confidence it will survive in the long run, both with longer L and shorter T than the alternative.

April 3, 2008

Is the emulation singularity near?

Filed under: PC Architecture,VM — Nate Lawson @ 6:00 am

While reading the book Computer Power and Human Reason, I began to wonder about emulation. Of course, any Turing machine can emulate any other (but possibly very slowly).  However, I am wondering if we’re near a singularity in whole-system emulation.

Whole-system emulation is where an entire computer, including CPU and peripherals, is emulated. This is different from a language VM (e.g., the JVM) or an OS VM (e.g., Linux UML). I gave a talk about VMs a few years ago that may be useful as a refresher. A whole system can be emulated by full instruction interpretation if the host CPU is a different architecture (e.g., Bochs or VICE) or by native execution with traps (e.g., VMware). The only difference is speed.

With the ever-growing prevalence of the x86 architecture, I am wondering whether we are near an emulation singularity. That is, a point in time where every machine ever produced in decent quantity, including every machine currently being sold, can be emulated at full speed on any widely-available desktop.

There are two classes of system that matter in this scenario: old and new machines. Old machines can be emulated via pure horsepower. When I run VICE, my virtual 6502 CPU, video chip, and sound chip are fully interpreted with cycle accuracy.  My desktop PC can be a Nintendo DS, numerous arcade games, or even a Playstation 2.  The fact that not only the main CPU but various custom graphics chips are being emulated is amazing.

New machines can be emulated at a decent speed if they share the same CPU architecture.  I think the spread of x86 is bringing us to that point in the near future.  Apple desktops and laptops, Sun servers, and the original Xbox are all based on x86 and can be emulated at full speed.  The advent of hardware virtualization makes it even easier to run multiple operating systems on the same platform.

There will continue to be new non-x86 systems (Xbox 360, Playstation 3, cellphones) but the gap is narrowing between their release and the appearance of the first emulator.  Since mainstream PCs are used as development platforms, the manufacturers themselves are designing the architecture to be emulated with a minimal amount of peripheral hardware (e.g., a chipset attached via USB).

Will we reach a singularity where every newly-released piece of mainstream hardware is readily emulated on current systems?  I think so — what do you think?

The Rubric Theme. Blog at WordPress.com.

Follow

Get every new post delivered to your Inbox.

Join 93 other followers