Month: November 2006

A loud present

Today, a friend of mine, Gerben, gave me a birthday present (a tad late). Not the usual beverages (turned 18 ;)) (usual, but still very well appreciated :)), but a home-made portable speaker with built-in amplifier. Here seen making more sound than the internal speaker of my Thinkpad:

dsc_0050.jpg

It’s a nifty little device: it’s powered by either an internal battery or an external power source.

dsc_0048.jpg

It contains a voltage converter and a rectifier which allows a variable AC power source to be connected. This has been added to be able to connect the speaker to the electrical generator of a bicycle. Why? The previous version of this speaker was taken on the bicycle trip with a few friends to the Hertog Jan Brewery in Arcen (~70km) which was only powered by a battery (which tends to be exhausted).

Even better, when set into external source mode it recharges the battery. And because of the voltage converter, the sound doesn’t get louder when you are cycling faster, but the quality of the sound gets better!

dsc_0051.jpgdsc_0049.jpgdsc_0047.jpg

I’ve had quite some fun dissecting the little device. Thanks again Gerben!

Simple Branch Prediction Analysis

This paper outlines simple branch prediction analysis attack against the RSA decryption algorithm.

At the core of RSA decryption is a loop over all bits of the secret key number d. When the bit 1 there is other code executed than when the bit is 0. The CPU branches on a different bit.

A spy process can be run on the CPU which measures the branch cache of the CPU by flooding the cache with branches and measuring the time it takes. When the sequentially running secret process doing RSA decryption makes a different branch (1 instead of 0) it can be noticed in a change of execution time on the spy process’s branches.

In this way quite a lot of secret bits can be derived.

There are some clear buts:

  • You must be able to insert a spy process on the computer itself and it should know exactly when the RSA process runs.
  • To attain clear readings, there shouldn’t be other processes claiming too much CPU time.
  • The spy and CPU process should run on the same physical processor and preferably at the same time (dual core)

An easy fix would be to allocate a whole processor for the RSA decryption time, so no process can spy. Another option would be to add noise in the Branch Prediction Buffer, but that would result in a performance loss.