9 Side Channel Assessment Platforms and Tools for Ubiquitous Systems
157
traditional SCA trace collection control loop model is not fast enough for efficient,
practical, trace acquisition. The main bottleneck in such control loops is the
presence of a PC device for providing inputs, collecting outputs and controlling each
execution of the DUT security/cryptography implementation [427]. The solutions
presented in the previous subsection, although they do not manage to eliminate
the need for a PC inside the control loop, clearly indicate a tendency to migrate
traditional PC-related functionality to other hardware or software entities that are
closely associated with the DUT. In some solutions, the control loop operations
are implemented in hardware and are downloaded on a dedicated control FPGA
that is physically connected to the DUT. This is done in the Sasebo/Sakura project
and in some ChipWhisperer (NewAE) technologies, just to name some examples.
Hardware, however, is not flexible and thus cannot be easily adapted to different
algorithms or assessment techniques. Similarly, control loop functionality is partially migrated on dedicated control loop ASIC microcontrollers or microprocessors
that operate alongside a PC in order to implement the DUT control in software. Such
solutions lack speed when transmitting DUT test vectors to the DUT itself since PC
usage is still needed.
Therefore, it has become apparent that a different, updated approach to realize
DUT control loops for SCA evaluation and leakage assessment is needed. In
this work, considering the previous paragraph’s described hardware and software
control loop limitations, we propose an approach that relies on a hardware/software
co-design solution for controlling the trace acquisition process. Extending and
generalizing the work in [427], we propose a three-step SCA trace collection
process. For this process to be possible, the control loop is not executed on a PC
but exclusively on a microcontroller that is directly connected to the DUT. The
microcontroller can be an ASIC (hard-core) or FPGA based (softcore) depending
on the SCA trace collection board at hand. Using software that is executable on the
microcontroller we gain the flexibility of a software control loop solution. Using
the microprocessor that is directly connected (through a bus interface) to the DUT
we gain very high control loop speed, which is not achievable using PC-based
control loops. More information on such an architecture can be found in the use
case example presented below.
In the first step of the proposed control trace collection process, denoted as the
design phase, the evaluator can describe in a programming or scripting language
(e.g., C, Python, JavaScript), using some developed Application Program Interface
(API), the SCA trace acquisition experiment that needs to be performed. The
experiment includes inputs that need to be provided to the DUT, specification
of the security/cryptography operations that need to be executed, the execution
sequence, the delay between experiment executions (in case the experiment needs
to be executed more than once) and DUT output storage. The goal of the design
phase is to fully specify the inputs, parameters and execution sequences of the
experiment. The outcome of this phase is an executable file that can be transmitted
to the microcontroller bootloader for execution.
The second step of the proposed control trace collection process, denoted as
the execution phase, is focused on the execution of the designed experiment. This
157
traditional SCA trace collection control loop model is not fast enough for efficient,
practical, trace acquisition. The main bottleneck in such control loops is the
presence of a PC device for providing inputs, collecting outputs and controlling each
execution of the DUT security/cryptography implementation [427]. The solutions
presented in the previous subsection, although they do not manage to eliminate
the need for a PC inside the control loop, clearly indicate a tendency to migrate
traditional PC-related functionality to other hardware or software entities that are
closely associated with the DUT. In some solutions, the control loop operations
are implemented in hardware and are downloaded on a dedicated control FPGA
that is physically connected to the DUT. This is done in the Sasebo/Sakura project
and in some ChipWhisperer (NewAE) technologies, just to name some examples.
Hardware, however, is not flexible and thus cannot be easily adapted to different
algorithms or assessment techniques. Similarly, control loop functionality is partially migrated on dedicated control loop ASIC microcontrollers or microprocessors
that operate alongside a PC in order to implement the DUT control in software. Such
solutions lack speed when transmitting DUT test vectors to the DUT itself since PC
usage is still needed.
Therefore, it has become apparent that a different, updated approach to realize
DUT control loops for SCA evaluation and leakage assessment is needed. In
this work, considering the previous paragraph’s described hardware and software
control loop limitations, we propose an approach that relies on a hardware/software
co-design solution for controlling the trace acquisition process. Extending and
generalizing the work in [427], we propose a three-step SCA trace collection
process. For this process to be possible, the control loop is not executed on a PC
but exclusively on a microcontroller that is directly connected to the DUT. The
microcontroller can be an ASIC (hard-core) or FPGA based (softcore) depending
on the SCA trace collection board at hand. Using software that is executable on the
microcontroller we gain the flexibility of a software control loop solution. Using
the microprocessor that is directly connected (through a bus interface) to the DUT
we gain very high control loop speed, which is not achievable using PC-based
control loops. More information on such an architecture can be found in the use
case example presented below.
In the first step of the proposed control trace collection process, denoted as the
design phase, the evaluator can describe in a programming or scripting language
(e.g., C, Python, JavaScript), using some developed Application Program Interface
(API), the SCA trace acquisition experiment that needs to be performed. The
experiment includes inputs that need to be provided to the DUT, specification
of the security/cryptography operations that need to be executed, the execution
sequence, the delay between experiment executions (in case the experiment needs
to be executed more than once) and DUT output storage. The goal of the design
phase is to fully specify the inputs, parameters and execution sequences of the
experiment. The outcome of this phase is an executable file that can be transmitted
to the microcontroller bootloader for execution.
The second step of the proposed control trace collection process, denoted as
the execution phase, is focused on the execution of the designed experiment. This