Side-Channel Power Analysis Series - Part 5 of 7
| Part | Title | Status |
|---|---|---|
| 1 | The Gap Between Mathematical Security and Physical Reality |  |
| 2 | Why Does Power Consumption Leak Secrets? | |
| 3 | AES - Understanding What We Are Attacking | |
| 4 | SPA, DPA and CPA - The Attack Ladder | |
| 5 - You are here | Hardware Setup and First Connection - Let’s Actually Do This | |
| 6 | Compiling Firmware, Setting Up Capture and Getting Your First Real Power Trace | |
| 7 | I Stole an AES Key by Watching a Chip’s Power Consumption | |
← Previous: Part 4: SPA, DPA and CPA - The Attack Ladder | Next → Part 6: Compiling Firmware and Getting Your First Power Trace
Part of the Side-Channel Power Analysis series on IoTSec.in
Okay. Four blogs of theory. We talked about side channels, power traces, AES internals, and CPA attacks. If you read all of that you’ve earned this one.
This is where we stop reading and start doing.
Blog 5 is split into three parts because there is a lot to cover and I don’t want anyone to feel rushed:
- Blog 5A: Hardware Setup and First Connection ← you are here
- Blog 5B: Capturing Your First Power Trace
- Blog 5C: Running the CPA Attack and Recovering the Key
Today’s goal is simple. By the end of this blog, your hardware will be connected, your software will be installed, and Python will be talking to both boards. That’s it. No capturing yet. Just connection.
Let me be honest I was nervous touching real hardware for the first time too. I asked a lot of basic questions. This blog is written the way I wish someone had explained it to me.
What I Found Confusing (And Now Don’t)
Before anything else the thing that confused me most at the start was the shunt resistor. I knew what a resistor does from basic electronics it reduces voltage. But I could not figure out why we were putting one on purpose in the power line. Wasn’t that going to mess things up?
Then I understood: we’re not trying to reduce anything. We’re using the voltage drop as a measurement point. Current flows through the shunt and a tiny voltage difference appears across it. ChipWhisperer reads that difference. That difference tells us exactly how hard the XMEGA is working at every moment in time.
The shunt resistor is not there to block. It’s there to give us something to listen to.
Once that clicked, everything else made sense.
The Hardware - What You Need
Two boards. One USB cable. One ribbon cable. That’s the whole setup.
Board 1: CW1173 - The ChipWhisperer-Lite Capture Board
This is the observer. It doesn’t do any encryption. It just watches.
Think of it like this. Imagine you want to know if someone is home inside a house. You can’t go inside. But you notice that every time someone moves around, the electricity meter outside spins a little faster. So you stand outside and watch the meter. From just that one signal power usage you figure out what’s happening inside.
The CW1173 is what stands outside and watches the meter.
Inside the CW1173 there are two important things:
The ADC (Analog to Digital Converter) — this is the actual sensor. Power consumption is an analog signal. It flows up and down smoothly, like a wave. The ADC converts that wave into thousands of numbers per second that your laptop can work with. Think of it like a very fast camera but instead of taking pictures of light, it takes snapshots of voltage.
On the CW1173, the ADC runs at 96 MHz. That means it takes 96 million snapshots per second. AES runs at around 7.3 MHz on the XMEGA. So the ADC captures many data points for every single clock cycle of the encryption. That’s why the traces are so detailed.
The FPGA (Spartan 6) - this is the brain that controls timing. It tells the ADC exactly when to start capturing, makes sure everything is synchronized with what the XMEGA is doing, and handles communication with your laptop. If you open the board and look, you’ll see the Spartan 6 chip that’s the FPGA.
You don’t need to program the FPGA yourself. ChipWhisperer’s firmware handles all of that.
The CW1173 is powered entirely by USB. One cable. No external power supply. Plug it into your laptop and it turns on.
Board 2: CW303 The XMEGA Target Board
This is the house. This is what we are attacking.
The CW303 has one main chip on it — the XMEGA microcontroller. This is the chip that runs AES. When you send it a plaintext and a key, it encrypts. That’s its whole job in this experiment encrypt, encrypt, encrypt, thousands of times, while CW1173 watches.
The other important component on the CW303 is the shunt resistor — labeled R1 on the board. As I explained above, this is our measurement point. The power line going into the XMEGA passes through R1. CW1173 clips onto both sides of R1 and reads the tiny voltage difference that appears as current flows through it.
Current flows through R1 unchanged — the XMEGA doesn’t even notice it’s there. But we can measure everything from outside.
Power supply
|
[R1 — Shunt Resistor] ← CW1173 measures voltage here
|
[XMEGA — running AES]
|
Ground
How The Two Boards Connect
The CW1173 and CW303 connect through a 20-pin ribbon cable. One end goes into CW1173, other end goes into CW303. The connector is keyed it only goes in one way. Don’t force it.
That one cable carries four things:
Power - CW1173 powers the CW303 completely. The target board has no separate power supply. Everything comes through this cable. If this cable isn’t connected, CW303 is dead. The green LED on CW303 is your confirmation that it’s receiving power.
Programming line - this is how ChipWhisperer loads firmware onto the XMEGA. Before we can attack, we need to put the AES program onto the target. CW1173 does that automatically through this cable. You don’t need a separate programmer.
Trigger line - this is the clever one. When the XMEGA starts AES, it raises a signal on one of its pins - basically saying “I am starting encryption right now.” CW1173 listens for that signal and starts the ADC at that exact moment. This is why all 1000 traces line up perfectly with each other. Every trace starts at the same point in the AES operation.
Without the trigger, CW1173 would be recording blindly. It wouldn’t know where in the recording the actual encryption happened. With the trigger — it captures exactly what we need, nothing more.
Serial communication — this is how Python sends plaintexts to the XMEGA and gets ciphertexts back. Your script sends a plaintext, XMEGA encrypts it, sends back the result. This is how we feed data to the attack.
CW1173 ←————— 20-pin ribbon cable ————→ CW303
Power, Trigger, Serial, Program
There are also two SMA connectors on CW1173 — one labeled Measure and one labeled Glitch. The Measure connector is what actually reads the voltage across R1. We are not using the Glitch connector in this series that’s for a different kind of attack (fault injection) which we’ll cover separately.
Installing ChipWhisperer on Linux
I am running Ubuntu. Any Debian-based Linux will work the same way. If you’re on Windows, check the official ChipWhisperer docs for the driver setup the Python steps are the same but you’ll need an extra USB driver step.
Why clone the repo instead of pip install directly?
You might have seen tutorials that say just run pip install chipwhisperer. On newer Ubuntu versions this will fail with an error about “externally managed environment.” Ubuntu now protects the system Python from pip installs.
The cleaner approach is to clone the full repository and use a virtual environment. This also means you get the Jupyter notebooks that come with ChipWhisperer those are what we’ll use to run the attack.
Step 1: Clone the repository
git clone https://github.com/newaetech/chipwhisperer
cd chipwhisperer
Step 2: Create a virtual environment
python3 -m venv cw_env
source cw_env/bin/activate
Your terminal prompt will change to show (cw_env) at the start. This means the environment is active. Every time you want to work with ChipWhisperer, you need to activate this environment first.
Step 3: Install ChipWhisperer
pip install -e .
The -e flag means editable install it installs directly from the cloned folder. You’ll see it pull in numpy, pyserial, libusb1, and a few other dependencies automatically. Let it finish.
Step 4: Install Jupyter manually
This one caught me. Jupyter is NOT in the requirements file, so it won’t install automatically. You have to add it yourself:
pip install jupyter
Step 5: Fix the USB permissions this is where most people get stuck
By default, Linux won’t let a regular user talk directly to USB devices. You need to tell Linux that ChipWhisperer is a trusted device.
The repo comes with a rules file for this. In older versions of ChipWhisperer this file was deep inside a subfolder. In the current version (6.0.0), it is right in the root folder of the cloned repo and it is called 50-newae.rules. Don’t go looking for it inside subdirectories — it won’t be there.
Run these commands:
sudo cp 50-newae.rules /etc/udev/rules.d/
sudo udevadm control --reload-rules
sudo udevadm trigger
Here is the replacement markdown:
Here is what actually happens. The rules file comes with three permission lines already written:
SUBSYSTEMS=="usb", ATTRS{idVendor}=="2b3e", ATTRS{idProduct}=="*", MODE="0664", GROUP="chipwhisperer"
SUBSYSTEM=="tty", ATTRS{idVendor}=="2b3e", ATTRS{idProduct}=="*", MODE="0664", GROUP="chipwhisperer"
SUBSYSTEM=="tty", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="6124", MODE="0664", GROUP="chipwhisperer"
The file’s own instructions tell you to run sudo usermod -aG chipwhisperer $USER. But on a fresh Ubuntu install that group doesn’t exist:
usermod: group 'chipwhisperer' does not exist
You can create the group and add yourself to it but even then the device stays owned by root and permission doesn’t apply cleanly. Skip the group entirely. Open the rules file:
sudo nano /etc/udev/rules.d/50-newae.rules
Add this one line at the bottom:
SUBSYSTEM=="usb", ATTR{idVendor}=="2b3e", ATTR{idProduct}=="ace2", MODE="0666"
Save and exit. Then reload:
sudo udevadm control --reload-rules
sudo udevadm trigger
This tells Linux give all users direct read/write permission to this specific device. No group needed.
To confirm your vendor and product IDs:
lsusb
# Bus 001 Device 018: ID 2b3e:ace2 NewAE Technology Inc. CW1173 [ChipWhisperer-Lite]
# Or more specifically:
udevadm info -a -n /dev/bus/usb/001/018 | grep -E 'idVendor|idProduct'
After making this change, unplug the board and plug it back in. The rule only applies when the device reconnects.
First Power On
Before you power on check two things:
- The 20-pin ribbon cable is connected firmly to both boards
- The USB cable is connected from CW1173 to your laptop
Now plug in the USB.
What you should see:
- Blue LED on CW1173 board is getting USB power ✓
- Green LED on CW303 target is getting power through the ribbon cable ✓
If the blue LED on CW1173 is off try a different USB cable. Some cables are charge-only and don’t carry data.
If CW1173 is lit but CW303 is dark — check the ribbon cable. It’s probably not seated fully.
Verify Linux sees the board:
lsusb
Look for this line:
Bus 001 Device 018: ID 2b3e:ace2 NewAE Technology Inc. CW1173 [ChipWhisperer-Lite]
If you see that — Linux recognizes the hardware. You’re ready for the software connection.
First Connection in Jupyter
Open a terminal, navigate to the chipwhisperer folder, activate your environment, and start Jupyter:
cd ~/chipwhisperer
source cw_env/bin/activate
jupyter notebook
Jupyter will open in your browser. Create a new notebook and type these three lines:
import chipwhisperer as cw
scope = cw.scope()
target = cw.target(scope)
print(scope)
What each line does:
import chipwhisperer as cw — loads the library.
scope = cw.scope() Python reaches out to the CW1173 and connects to it. This is the capture board.
target = cw.target(scope) Python reaches through CW1173 to the CW303. This is the XMEGA target board.
print(scope) prints everything ChipWhisperer knows about your setup.
If it works, you’ll see something like this:
cwlite Device
fw_version =
major = 0
minor = 64
debug = 0
adc =
state = False
samples = 24400
adc_freq = 96000000
clock =
adc_locked = True
clkgen_locked = True
trigger =
triggers = tio4
io =
target_pwr = True
The important things to look for:
fw_versionshows up board responded ✓adc_locked = TrueADC clock is stable ✓clkgen_locked = Trueclock generator stable ✓target_pwr = TrueCW303 is being powered ✓
You might also see this warning:
Your firmware (0.64.0) is outdated - latest is 0.65.0
Ignore it. The board works perfectly on 0.64.0. This warning won’t affect the attack.
What To Do If You Get an OSError
The most common error beginners hit looks like this:
OSError: Unable to communicate with found ChipWhisperer.
Check that another process isn't connected to it and
that you have permission to communicate with it.
This means Linux found the board (lsusb shows it) but Python can’t talk to it. Almost always a permissions issue.
Fix: make sure you added the udev rule line I showed above, unplugged and replugged the board after adding it, and reloaded udev rules. If you did all that and it still fails run:
sudo udevadm control --reload-rules
sudo udevadm trigger
Then unplug, replug, and try again.
Every Time You Start Working
This is easy to forget. Every new terminal session:
cd ~/chipwhisperer
source cw_env/bin/activate
jupyter notebook
The virtual environment doesn’t activate automatically. If you open a new terminal and run Python without activating first, it won’t find the ChipWhisperer library.
What We Learned — Glossary
CW1173 - the ChipWhisperer-Lite capture board. Contains the FPGA and ADC. Connects to laptop via USB. Watches the power line of the target.
CW303 - the XMEGA target board. Runs AES firmware. Gets attacked. Powered through the 20-pin cable.
FPGA (Spartan 6) - the programmable chip on CW1173 that controls timing and synchronization. Tells the ADC exactly when to start capturing.
ADC - Analog to Digital Converter. Converts the analog power signal into numbers your laptop can read. Runs at 96 MHz on the CW1173.
XMEGA - the microcontroller on CW303 that runs AES. This is our target.
Shunt resistor (R1) - a tiny resistor on the CW303 power line. Current flows through it unchanged, but a small voltage drop appears across it. CW1173 measures that drop to calculate current.
Voltage drop - when current flows through any resistance, a small voltage difference appears across it. This is the measurement point. Current doesn’t decrease — only voltage drops slightly.
20-pin ribbon cable - connects CW1173 and CW303. Carries power, programming, trigger signal, and serial communication.
Trigger - the signal the XMEGA sends when AES starts. CW1173 listens for this and starts capturing at that exact moment. This is why all traces align correctly.
udev rules - Linux rules that control which users can access USB devices. ChipWhisperer needs a custom rule so Python can talk to it without root privileges.
Virtual environment - an isolated Python environment. Keeps ChipWhisperer’s dependencies separate from system Python. Activate it before every session.
What’s Next
In Blog 5B, we load the AES firmware onto the XMEGA, set up the capture parameters, and capture our first real power trace. That’s where you’ll see an actual power trace for the first time messy, noisy, and completely unlike the clean diagrams from earlier blogs. We’ll talk about why that’s completely normal and how to read it.
Blog 5B: Capturing Your First Power Trace → coming next