9 Side Channel Assessment Platforms and Tools for Ubiquitous Systems
155
There is limited variety of commercial SCA boards, each with its pros and cons.
The Cryptographic Engineering Research Group (CERG) presented the FOBOS
board [565, 566], which consists of two FPGA’s, one for handling control tasks
and one for the implementation of the cryptographic algorithm. The FOBOS
board contains a Digital Clock Manager that produces frequencies in the range
of 31.25 kHz up to 50 MHz for the Victim Board. The communication with the
Control FPGA is performed through a software control loop that is responsible
for transmitting the appropriate commands and the necessary data to the victim
FPGA. The software loop is also responsible for the communication with the
oscilloscope (currently supporting only Agilent oscilloscopes). Unfortunately, the
FOBOS approach relies on old FPGA boards, is not capable of automated multiple
trace collection through the provided control loop, is only applicable to a specific
type of oscilloscope, and involves the PC in each trace collection (part of the control
loop) which considerably burdens the collection speed.
The Tamper-resistance Standardization Research Committee (TSRC) released
two trace collection hardware boards [399]. The first is INSTAC-8 which uses an
8-bit microcontroller and the second is INSTAC-32 with a 32-bit microcontroller
as the control component and an FPGA chip as the DUT. Unfortunately, very
limited information is provided on the clock frequencies and the communication
methods that those two boards employed. Similarly to FOBOS, they also featured
some custom-made software loops for the communication between the users and
the victim chips. An evolution of the above approaches is the Sakura-Sasebo
Project [354], which provides several choices regarding measurement boards.
Initially, low-end-based chip boards were implemented, leading to the Sasebo-G,
Sasebo-GII and Sasebo-W solutions, which for several years constituted the most
widely used platforms for trace collection. Later, more sophisticated versions of
those boards were launched, the Sakura-G, Sakura-X and Sakura-W. Both SakuraG and Sakura-X contain two FPGAs each (a Control FPGA acting as the control
component and a cryptography FPGA acting as the DUT), making them perfect
for evaluation of hardware-implemented cryptographic algorithms, while Sakura-W
was suitable for evaluation of smartcard security. Unfortunately, the boards are still
supported by a primitive interface on the Control FPGA that enables the interfacing
of a particular cryptographic algorithm with limited key-length. Also, the provided
software loop in charge of data and command transmission to the Cryptographic
FPGA is slow, oriented towards a specific algorithm with fixed key-length, and
offers through a PC program very basic functionality only for a single trace capture
per loop round.
An attempt to remedy this issue was made in the IAMeter project, which is
focused exclusively on developing an efficient control loop for commercial and
custom FPGA board platforms (including the Sasebo-G and GII boards) [307].
However, even this attempt can provide only a single trace collection per loop round,
it is not capable of adjusting/controlling the DUT clock, and it relies heavily on
PC-based configurations (including Python scripts along with MySQL databases
queries) which slow the trace collection as a whole.
155
There is limited variety of commercial SCA boards, each with its pros and cons.
The Cryptographic Engineering Research Group (CERG) presented the FOBOS
board [565, 566], which consists of two FPGA’s, one for handling control tasks
and one for the implementation of the cryptographic algorithm. The FOBOS
board contains a Digital Clock Manager that produces frequencies in the range
of 31.25 kHz up to 50 MHz for the Victim Board. The communication with the
Control FPGA is performed through a software control loop that is responsible
for transmitting the appropriate commands and the necessary data to the victim
FPGA. The software loop is also responsible for the communication with the
oscilloscope (currently supporting only Agilent oscilloscopes). Unfortunately, the
FOBOS approach relies on old FPGA boards, is not capable of automated multiple
trace collection through the provided control loop, is only applicable to a specific
type of oscilloscope, and involves the PC in each trace collection (part of the control
loop) which considerably burdens the collection speed.
The Tamper-resistance Standardization Research Committee (TSRC) released
two trace collection hardware boards [399]. The first is INSTAC-8 which uses an
8-bit microcontroller and the second is INSTAC-32 with a 32-bit microcontroller
as the control component and an FPGA chip as the DUT. Unfortunately, very
limited information is provided on the clock frequencies and the communication
methods that those two boards employed. Similarly to FOBOS, they also featured
some custom-made software loops for the communication between the users and
the victim chips. An evolution of the above approaches is the Sakura-Sasebo
Project [354], which provides several choices regarding measurement boards.
Initially, low-end-based chip boards were implemented, leading to the Sasebo-G,
Sasebo-GII and Sasebo-W solutions, which for several years constituted the most
widely used platforms for trace collection. Later, more sophisticated versions of
those boards were launched, the Sakura-G, Sakura-X and Sakura-W. Both SakuraG and Sakura-X contain two FPGAs each (a Control FPGA acting as the control
component and a cryptography FPGA acting as the DUT), making them perfect
for evaluation of hardware-implemented cryptographic algorithms, while Sakura-W
was suitable for evaluation of smartcard security. Unfortunately, the boards are still
supported by a primitive interface on the Control FPGA that enables the interfacing
of a particular cryptographic algorithm with limited key-length. Also, the provided
software loop in charge of data and command transmission to the Cryptographic
FPGA is slow, oriented towards a specific algorithm with fixed key-length, and
offers through a PC program very basic functionality only for a single trace capture
per loop round.
An attempt to remedy this issue was made in the IAMeter project, which is
focused exclusively on developing an efficient control loop for commercial and
custom FPGA board platforms (including the Sasebo-G and GII boards) [307].
However, even this attempt can provide only a single trace collection per loop round,
it is not capable of adjusting/controlling the DUT clock, and it relies heavily on
PC-based configurations (including Python scripts along with MySQL databases
queries) which slow the trace collection as a whole.