ChipWhisperer Hardware Security Toolchain for Power Analysis

ChipWhisperer's Hardware Security Research Scope

ChipWhisperer addresses a hardware-oriented security problem: acquiring observable side-channel data from an embedded target and analyzing that data alongside the target's behavior. Its intended users are hardware security researchers working on power analysis and glitching attacks. The repository describes a complete toolchain rather than a single script or library.

The system is divided into three connected layers. The hardware layer consists of a capture board and a separate target board. Open schematics and PCB layouts are available for the ChipWhisperer-Husky capture board and several target boards. This separation matters because trace acquisition requires physical equipment, while the target under test performs the computation or firmware operation that produces the signals being studied.

The firmware layer also spans several environments. A C firmware component controls the capture board over USB, Verilog firmware configures the FPGA for high-speed capture, and target-specific firmware examples operate on the device being examined. The software layer exposes Python APIs for hardware control through ChipWhisperer Capture and trace processing through ChipWhisperer Analyzer. A researcher therefore adopts a coordinated stack rather than using Analyzer as an isolated Python package.

From Capture Board to Python Trace Analysis

The acquisition path starts with the capture board, which observes a target and sends captured information to the host through its USB controller. The repository identifies that controller as C firmware and the high-speed capture implementation as Verilog firmware. ChipWhisperer Capture provides the Python-side interface for communicating with this hardware. The documentation does not describe a universal trace format here, but it clearly places device communication inside the Capture layer rather than treating hardware control as part of Analyzer.

Analyzer then handles power traces obtained from ChipWhisperer hardware. The repository lists its analysis dependencies, including NumPy, Numba, ECpy, Zarr, tqdm, and pycryptodome. ChipWhisperer 7.0 introduces Zarr-based projects, integer math, iterators for KTP classes, a new CPA attack class, and an updated results API. The README also says the project and analyzer APIs have been simplified.

That version boundary is important for adoption. The repository announces ChipWhisperer 7.0 changes while also stating that the previous API remains available at tag `v6.1.0`. Existing scripts written for the previous API may therefore need review before they are moved to the newer project structure. The announcement mentions API simplification, but it does not claim that older code runs unchanged.

Firmware and Repository Boundaries for ChipWhisperer

ChipWhisperer's firmware examples support the target side of experiments, while the software and firmware directories separate host tooling, embedded code, notebooks, and hardware integration work. The repository includes `firmware/`, `software/`, `openadc/`, `openocd/`, `jupyter/`, and `tests/` at the top level. That layout reflects the breadth of the project and also means contributors should expect more than a single Python package.

The package metadata locates Python packages under `software`:

[tool.setuptools.packages.find]
where = ["software"]

The build backend is setuptools, with `setuptools >= 61.0` and `setuptools_scm>=8` listed as build requirements. ChipWhisperer itself requires Python 3.11 or newer. Runtime dependencies include hardware communication libraries such as `pyserial` and `libusb1`, numerical packages such as `numba` and `numpy>=2.0.0`, and an optional `trace` dependency group.

This dependency set indicates that Analyzer is coupled to a larger scientific and hardware-support stack. Installing the Python distribution does not turn an ordinary computer into a capture platform. The required acquisition path still depends on supported hardware, its firmware, a target board, and the physical experiment setup described by the project documentation.

Starting with ChipWhisperer Documentation and SCA101

The README directs first-time users to the ChipWhisperer documentation for setup instructions. It does not provide a shell installation command, supported operating system matrix, hardware assembly procedure, or a complete first-capture example. The correct starting point is the documentation linked from the README, followed by the SCA101 labs.

The repository links an online course at `learn.chipwhisperer.io` and separately links lab material in the `chipwhisperer-jupyter` repository under the `sca101` branch.

For a first real use, a researcher should first identify the acquisition hardware and target, then use the corresponding setup instructions in the documentation. Once communication is configured, the Capture layer handles hardware interaction. Analyzer is the relevant component for processing acquired power traces and examining CPA results.

ChipWhisperer 7.0 Migration and Analyzer Trade-offs

ChipWhisperer 7.0 changes several internals that affect research scripts. Projects move to Zarr, the Analyzer API is simplified, and the new CPA attack class is described as having major performance improvements. The README also records a shift to integer math, a revised results API, removal of unmaintained Analyzer parts, and porting of the MixColumns attack into Analyzer.

These changes can reduce the amount of obsolete Analyzer code, but removal is also a compatibility boundary. Researchers who depend on removed components must identify the replacement before upgrading. The repository explicitly offers tag `v6.1.0` for users who need the previous API, which makes that tag the relevant reference point for a controlled comparison.

The Zarr-based project format should be checked against stored datasets and existing analysis notebooks. The README does not state whether old project files are converted automatically, whether every analysis path is compatible, or what rollback procedure applies to a saved experiment. A practical migration assessment therefore needs to compare the scripts, project data and expected Analyzer outputs. Performance claims about the new CPA class are part of the project announcement, not independent measurements.

Where ChipWhisperer Is the Wrong Tool

ChipWhisperer is the wrong choice when the task is limited to analyzing an existing power trace on a host computer and no ChipWhisperer acquisition chain is involved. Although Analyzer has Python APIs for trace processing, the repository presents Analyzer as one layer of a toolchain whose Capture component communicates with particular hardware. A generic trace file may require different software and format support.

It is also unsuitable for evaluating a device without arranging a controlled target experiment. Capture boards, target firmware, trigger behavior and the physical measurement setup are part of the system described by the project. The README does not promise that every embedded device can be attached directly, nor does it document a universal adapter for arbitrary hardware.

ChipWhisperer should not be mistaken for a general firmware reverse-engineering suite or a replacement for protocol-specific security tooling. Its stated scope is power analysis and glitching attacks. A researcher whose primary requirement is static firmware inspection, source-code scanning or conventional software vulnerability detection would need a tool built for that operation instead.

ChipWhisperer Versus Host-Only Trace Processing

The meaningful alternative is a host-only numerical analysis environment that ingests an existing trace without controlling capture hardware. Such an approach can fit a researcher who already has compatible traces and needs numerical processing, but it removes the acquisition and target integration supplied by ChipWhisperer.

ChipWhisperer takes a broader, hardware-coupled approach. It includes capture-board and target-board designs, C and Verilog firmware, target firmware examples, a hardware-control Python API and an Analyzer API. The host-only alternative would begin after measurement and would not solve board configuration, capture timing or firmware-triggered experiments through this project.

The choice depends on where the work begins. Use a host-only workflow when acquisition is already complete and compatible. Choose ChipWhisperer when the experiment must coordinate a capture board, target behavior and trace analysis. For acquisition data exchange, the repository shows that ChipWhisperer 7.0 uses Zarr-based projects and declares `zarr>=3.0.0`; compatibility with an existing dataset must therefore be checked before selecting the new project model.

License, Maintenance, and Upgrade Cost for ChipWhisperer

The repository is not archived, and its last push was on 2026-10-09. That establishes recent repository activity at the time of this review, but it does not by itself guarantee compatibility with a particular target or stable behavior for every component. The most recent listed releases are `sca101_release` on 2026-08-31, `v6.0.0b` on 2025-03-26 and `5.7.0` on 2025-01-24.

The package metadata points to `LICENSE.txt`, and the repository license is classified as Other rather than a standard license identifier. Anyone using, modifying or redistributing the software must inspect that file and account for its actual terms. The README also states that ChipWhisperer is a NewAE Technology Inc. trademark registered in the US, Europe and China. Trademark status and code licensing are separate matters.

Upgrade cost extends beyond package installation. ChipWhisperer 7.0 changes project storage, the Analyzer API, the CPA implementation and results access. Researchers may need to migrate notebooks, adapt scripts and verify saved trace projects. The availability of tag `v6.1.0` provides a documented reference for previous-API work, while the README does not document a general rollback procedure for hardware, firmware or Zarr projects.

Editorial conclusion

ChipWhisperer suits hardware security laboratories that need coordinated acquisition, target firmware, trace processing, and repeatable CPA workflows. It does not fit a software-only trace analysis task or an experiment that lacks compatible capture and target hardware. Before adoption, verify support for the intended target board, the API version required by the workflow, the custom license terms, and whether the 7.0 project format matches existing traces and scripts.

Frequently asked questions

Official sources

1. Issues
2. newaetech/chipwhisperer on GitHub
3. Project website
4. README
5. Releases