4.11 Analytical Review of Basic Techniques …
435
gate level [276]. The analysis allows to quantify the difficulty of activating each line
of a code or signal and ensure observing internal signals through primary outputs.
By revising the design and eliminating low testable nets, it is possible to improve
hardware Trojan detection. However, these analyses are not sufficient for an RTL or
gate-level design since they do not take the circuit’s function into account during the
analysis. For some security-critical modules (such as encryption/decryption blocks),
it is necessary to increase their security level at the design phase. Moreover, the hardware Trojan vulnerability analysis can be extended to the system and layout level.
At the system level, the design-for-trust techniques for trustworthy computing can
be used to ensure the security of critical computation blocks. Developers can decide
whether to sacrifice some die area and circuit performance to make the system architecture immune to hardware Trojan attacks. It can be very helpful to do vulnerability
analysis at the layout level, because it is the last step in the design. Limitation of
the available space (for example, the built-in self-authentication mechanism method)
can prevent hardware Trojan insertion by untrusted manufacturers (attack model B)
[299].
4.11.6.3 Trojan-Resistant IC Design
Because it is very hard to detect or prevent the presence of hardware Trojans in
the IC structure, providing functional resistance to hardware Trojans is another way
to protect the projects from Trojan insertion. Trojan-resistant design, as shown in
[259], mainly employs three approaches: the first approach is trying to eliminate
Trojan’s behaviors. A few examples of Trojan-resistant designs or structures that are
tolerant to Trojan effects even if hardware Trojans are present in a design have been
discussed above. For example, trustworthy computing is achieved by using diverse
IP-cores for the same task. Another approach aims at prevention of a hardware Trojan
from triggering. Since most Trojans are activated conditionally, it also provides an
opportunity to achieve reliable and trusted operations on the hardware platform with
Trojans by avoiding triggering these Trojans.
The third approach is to prevent hardware Trojan insertion. Several techniques
described above aim to hamper reverse engineering the design function by attackers
at an untrusted foundry so as to prevent targeted hardware Trojan attacks. Those
techniques in paper [259] mainly focus on the attack model B, while for the rest of
the models almost no attention was paid—this is a topic for further research.
4.11.6.4 Appearance of New Types of Hardware Trojans
Now we are aware of that hardware Trojans can be inserted at any development stage
from specification to assembly and package. Besides the third-party IP-core vendor
and foundry, the third-party testing and assembly companies can also take part in the
IC development process. However, nearly all known papers discuss hardware Trojans
and countermeasures that are aimed at the Trojans inserted either at the design or
435
gate level [276]. The analysis allows to quantify the difficulty of activating each line
of a code or signal and ensure observing internal signals through primary outputs.
By revising the design and eliminating low testable nets, it is possible to improve
hardware Trojan detection. However, these analyses are not sufficient for an RTL or
gate-level design since they do not take the circuit’s function into account during the
analysis. For some security-critical modules (such as encryption/decryption blocks),
it is necessary to increase their security level at the design phase. Moreover, the hardware Trojan vulnerability analysis can be extended to the system and layout level.
At the system level, the design-for-trust techniques for trustworthy computing can
be used to ensure the security of critical computation blocks. Developers can decide
whether to sacrifice some die area and circuit performance to make the system architecture immune to hardware Trojan attacks. It can be very helpful to do vulnerability
analysis at the layout level, because it is the last step in the design. Limitation of
the available space (for example, the built-in self-authentication mechanism method)
can prevent hardware Trojan insertion by untrusted manufacturers (attack model B)
[299].
4.11.6.3 Trojan-Resistant IC Design
Because it is very hard to detect or prevent the presence of hardware Trojans in
the IC structure, providing functional resistance to hardware Trojans is another way
to protect the projects from Trojan insertion. Trojan-resistant design, as shown in
[259], mainly employs three approaches: the first approach is trying to eliminate
Trojan’s behaviors. A few examples of Trojan-resistant designs or structures that are
tolerant to Trojan effects even if hardware Trojans are present in a design have been
discussed above. For example, trustworthy computing is achieved by using diverse
IP-cores for the same task. Another approach aims at prevention of a hardware Trojan
from triggering. Since most Trojans are activated conditionally, it also provides an
opportunity to achieve reliable and trusted operations on the hardware platform with
Trojans by avoiding triggering these Trojans.
The third approach is to prevent hardware Trojan insertion. Several techniques
described above aim to hamper reverse engineering the design function by attackers
at an untrusted foundry so as to prevent targeted hardware Trojan attacks. Those
techniques in paper [259] mainly focus on the attack model B, while for the rest of
the models almost no attention was paid—this is a topic for further research.
4.11.6.4 Appearance of New Types of Hardware Trojans
Now we are aware of that hardware Trojans can be inserted at any development stage
from specification to assembly and package. Besides the third-party IP-core vendor
and foundry, the third-party testing and assembly companies can also take part in the
IC development process. However, nearly all known papers discuss hardware Trojans
and countermeasures that are aimed at the Trojans inserted either at the design or