SCALE: hardware-oriented material
The equipment used for a typical side-channel attack based on power analysis might resemble the following:
.... +-------------+
/ | SCALE |
+-------------+ +-------------+ trigger +-------------+ | target |
| control | USB | acquisition | <--------- | target | | board |
| platform | <-----> | platform | signal | platform | +-------------+
| | | | <--------- | | | SCALE |
+-------------+ +-------------+ +-------------+ | host |
^ ^ \ | board |
| USB | .... +-------------+
+--------------------------------------------------+
The basic idea is that
-
the target platform represents the device under attack, or the Device Under Test (DUT) in more common terms,
-
the acquisition platform represents a device, e.g., an oscilloscope, to capture a signal from the target platform (under control of a trigger) and relay it to the control platform,
-
the control platform represents a workstation, which orchestrates the attack by controlling the target and acquisition platforms: it will often repeat an acquisition loop, i.e.,
- configure (e.g., fix the acquisition period) and initialise (e.g., arm the trigger) the acquisition platform,
- send input (e.g., plaintext) to target platform,
- invoke operation (e.g., encryption) on target platform,
- receive output (e.g., ciphertext) from target platform, then,
- receive trace from acquisition platform,
to acquire a set of traces, then apply some (crypt)analytic technique to them in order to recover information.
None of the above is an unreasonable expectation within the context of a research-oriented lab. but may present challenges in a teaching-oriented alternative. For example, particularly at scale, it may be that
- the Total Cost of Ownership (TCO), i.e., capital investment plus maintenance,
- the domain-specific requirements on Commercial Off-The-Shelf (COTS) target boards, such as the need to insert a shunt resistor into the power rail,
- the need to expose at least some EE-style detail to students without a suitable background,
prevent such an approach being viable (or make it less effective).
This repo. captures a suite of bespoke, hardware-based target platform designs: when combined with suitable control and acquisition platforms, it offers a real, albeit sanitised "kit" for learning about side-channel attacks. It has a strict remit, namely educational use (e.g., as a lab. exercise or assignment), which to some extent determines goals, design decisions, and, ultimately, the content.
-
Install any pre-requisites, e.g., support for Git Large File Storage (LFS) (without this, some content will appear as a set of pointers to data vs. the data itself).
-
Clone the repo.
git clone https://github.com/danpage/scale-hw.git ./scale-hw cd ./scale-hw git submodule update --init --recursive source ./bin/conf.sh
-
Create and populate a suitable Python virtual environment based on
${REPO_HOME}/requirements.txt
by executingmake venv
then activate it by executing
source ${REPO_HOME}/build/venv/bin/activate
-
Select a target board, e.g., by setting the environment variable
export TARGET="lpc1313fbd48"
-
Build the material by executing
make --directory="${REPO_HOME}/src/scale/target/${TARGET}" build
-
Make use of the material in
${REPO_HOME}/build/${TARGET}
e.g.,
-
build the example:
make --directory="${REPO_HOME}/src/scale/example" --file="${REPO_HOME}/build/${TARGET}/lib/scale.mk" PROJECT="example" BSP="${REPO_HOME}/build/${TARGET}" USB="/dev/ttyUSB0" build
-
program the example (i.e., execute it on physical hardware):
make --directory="${REPO_HOME}/src/scale/example" --file="${REPO_HOME}/build/${TARGET}/lib/scale.mk" PROJECT="example" BSP="${REPO_HOME}/build/${TARGET}" USB="/dev/ttyUSB0" program
-
emulate the example (i.e., execute it on virtual hardware):
make --directory="${REPO_HOME}/src/scale/example" --file="${REPO_HOME}/build/${TARGET}/lib/scale.mk" PROJECT="example" BSP="${REPO_HOME}/build/${TARGET}" USB="/dev/ttyUSB0" emulate
-