4.11 Analytical Review of Basic Techniques …
419
It should be noted that this functional validation of Trojans in the IC also has its advantages and disadvantages, which are generally specific to all known functional testing
systems.
The next important stage in the fight against hardware Trojans embedded in the IC
is the analysis of the chip description in the high-level language HDL (device design
language) for the so-called unruly Trojan behavior code [191], and for a similar
structural code [20] which allows to identify so-called redundant statements or thirdparty circuits that are potentially part of such hardware Trojan. Structural analysis
of the chip can also measure some quantitative indicators and characteristics of the
IC to determine “suspicious” signals or gates with low activation probability (Trojan
Hunters took care of that [276, 277]). It should be noted that even beginner Trojan
hunters Oya et al. [278] attempt to identify the main vulnerabilities by extracting
Trojan features from several existing Trojan benchmarks. However, main limitations
of code/structural analysis techniques are that they do not guarantee Trojan detection. The complex individual “manual” postprocessing is required to analyze any
suspicious signals or gates and determine if they are a part of a Trojan.
It is worth emphasizing that so-called formal verification of the project is a standard algorithmic-based approach to logic verification of the IC that proves (or denies)
a pre-defined set of security properties required by such a project and formulated by
world famous reputable Trojan hunters, including [191, 279, 280].
It is worth to note that when organizing the process to check the design conformity
to these properties, any similar project of “safe” IC design for critical applications
will be converted to some formal special format of the project that is convenient to
check the probability of presence of hardware Trojans in the IC, see for example (Coq
[281]). However, the use of various well-known methods of formal verification of
events could fail to detect additional unexpected logical functions that are absolutely
related to a possible Trojan.
Design-for-Trust
As described in the previous section, as of the date of this book, the issue of detecting
a quiet, low overhead hardware Trojan is still very challenging even with new techniques. As the great majority believes, a more effective way is to provide measures
against Trojan insertion, primarily at the design stage performed by the “reliable”
party. Therefore, depending on the specific security objectives, all known methodologies are divided into a number of areas that we will discuss below, including a
design-for-trust method aimed at organizing approaches to detect Trojans through
special measures.
Facilitation of functional test. Triggering the hardware Trojan inserted by the
intruder through standard design channels and observing the Trojan effect from
outputs of the analyzed circuit are difficult due to the stealthy nature of Trojans. A
large number of low-controllable and low-observable nets in the circuit interconnecting millions of transistors/IC components significantly hinder the possibility of
activating a Trojan. Salmani et al. [282] and Zhou et al. [283] tried to improve controllability of this complex process and observability of nodes by inserting special test
points hidden from observers into a protected microchip. Another approach proposes
419
It should be noted that this functional validation of Trojans in the IC also has its advantages and disadvantages, which are generally specific to all known functional testing
systems.
The next important stage in the fight against hardware Trojans embedded in the IC
is the analysis of the chip description in the high-level language HDL (device design
language) for the so-called unruly Trojan behavior code [191], and for a similar
structural code [20] which allows to identify so-called redundant statements or thirdparty circuits that are potentially part of such hardware Trojan. Structural analysis
of the chip can also measure some quantitative indicators and characteristics of the
IC to determine “suspicious” signals or gates with low activation probability (Trojan
Hunters took care of that [276, 277]). It should be noted that even beginner Trojan
hunters Oya et al. [278] attempt to identify the main vulnerabilities by extracting
Trojan features from several existing Trojan benchmarks. However, main limitations
of code/structural analysis techniques are that they do not guarantee Trojan detection. The complex individual “manual” postprocessing is required to analyze any
suspicious signals or gates and determine if they are a part of a Trojan.
It is worth emphasizing that so-called formal verification of the project is a standard algorithmic-based approach to logic verification of the IC that proves (or denies)
a pre-defined set of security properties required by such a project and formulated by
world famous reputable Trojan hunters, including [191, 279, 280].
It is worth to note that when organizing the process to check the design conformity
to these properties, any similar project of “safe” IC design for critical applications
will be converted to some formal special format of the project that is convenient to
check the probability of presence of hardware Trojans in the IC, see for example (Coq
[281]). However, the use of various well-known methods of formal verification of
events could fail to detect additional unexpected logical functions that are absolutely
related to a possible Trojan.
Design-for-Trust
As described in the previous section, as of the date of this book, the issue of detecting
a quiet, low overhead hardware Trojan is still very challenging even with new techniques. As the great majority believes, a more effective way is to provide measures
against Trojan insertion, primarily at the design stage performed by the “reliable”
party. Therefore, depending on the specific security objectives, all known methodologies are divided into a number of areas that we will discuss below, including a
design-for-trust method aimed at organizing approaches to detect Trojans through
special measures.
Facilitation of functional test. Triggering the hardware Trojan inserted by the
intruder through standard design channels and observing the Trojan effect from
outputs of the analyzed circuit are difficult due to the stealthy nature of Trojans. A
large number of low-controllable and low-observable nets in the circuit interconnecting millions of transistors/IC components significantly hinder the possibility of
activating a Trojan. Salmani et al. [282] and Zhou et al. [283] tried to improve controllability of this complex process and observability of nodes by inserting special test
points hidden from observers into a protected microchip. Another approach proposes