Side Channel Timing Attack

I decided to have a play with some side channel analysis attacks, What seemed like the easiest to attempt is a timing attack, so here is my findings.

All the code for this is available at https://rossmarks.uk/git/0xRoM/Hardware in the “/SideChannel/ATtiny85_Timing_Attack” directory.

Setup

To start with I’m going to use the trusty ATtiny85, it’s easy to program and so cheap it doesn’t matter if I accidentally break one.

I wired it up like so:

Walking through this. on the left of the breadboard is the ATtiny85. The wires that go off to the left are TX and RX for UART / serial debugging. To the Right of the ATtiny85 we have 4 buttons for input and right of those we have 2 LED’s (1 red and 1 green) for output.

Controlling the LED’s from 1 pin: https://www.batsocks.co.uk/readme/p_tut_led16.htm
Controlling the buttons from 1 pin: https://www.instructables.com/How-to-Multiple-Buttons-on-1-Analog-Pin-Arduino-Tu/

When it’s all put together it looked like:

Experiment 1 – Simple PIN

First I flashed the code “4_digit.ino” into the ATtiny85 which is very simple.
It has a hardcoded 4 digit pin. the user can either push a button (1 to 4) or type over serial the corresponding number. Once 4 digits have been entered it checks each digit one at a time. As soon as a digit it incorrect it exits the checking loop and lights up the red “incorrect” LED. otherwise if the loop completes the green LED flashes.

The pseudocode looks something like:

The side channel we are monitoring is the time between correct and incorrect passwords.
Since the loop is checking each character one at a time as soon as it reaches an incorrect character it exits. This means that an incorrect password will have a quicker response time than a correct one.

If the password is “2323” and we test “1111” the program will see the first 1 and exit – wow that was quick.
We then test “2222”, the program checks the first digit (it’s correct) then checks the second digit (it’s incorrect) and exits.
since that second operation had an additional check it would take a little bit longer we can then infer that the correct first digit is 2.
we can then go on to test “2111”, “2222”, “2333” and “2444”, whichever took the longest of these we then have the correct second digit, and so on until we have the entire password.

While it would be possible to wire a device up to each of the buttons and the LED’s and write some code to manually simulate the button presses and monitor the LED’s power it was much easier to interact with the serial console as it works just the same.

I then created “4_digit_attack.py” which worked briliantly. It tries the same password X amount of times (default 3) and gets the average response time for that pin before trying the next, this gives a more accurate reading as it takes into account fluctuations in timings.

This worked brilliantly.. so on to the next experiment:

Experiment 2 – Unknown PIN

As the title suggests I then wanted to make it so I didn’t know the PIN. For this experiment use the code:
multi_digit.ino – ATtiny85 program.
multi_digit_attack.py – Attacking script.

The main difference here is when the ATtiny85 first boots it generates a PIN with a random length between 4 and 8 digits long.

Running the attacking script I got the following results:

When the device generated a longer pin:

A little over 13 mins to crack an 8 digit pin, I think thats pretty good.

The script could be optimized to quit as soon as the response contained “correct” (or the green led comes on) this would greatly reduce the time to crack if a pin had repeating characters at the end, but I wanted to get the pin by just examining the timing.

Thats all for the little experiments I was playing with on the weekend. I hope this has helped someone, I recommend trying it – it was a lot of fun!

Sharing is caring!