7.4 Using Classic Methods of Reliable …
687
transmission lines. This extremely simple structure can be detected in several types
of Trojan implementation (for instance, side channels, independent synchronization,
or ambient temperature measurement). As is know, ring oscillators are also used
legitimately (e.g., random number generators and physical uncloneable functions).
However, since they are structures used in multiple examples of Trojans, they were
also included in the knowledge base in [72]. In order to detect such structures, many
rules can be invented. The work [72] contains the following rules aimed at reducing
the risk of using an embedded ring oscillator:
• In formal verification: a specific rule forbids substructures with outputs, but
without digital inputs;
• On source-code level: a rule reports the use of optimizing-inhibiting compiler- or
source-code flag (e.g., keep—i noprune—codes in the VHDL). In this specific
case, most synthesis means will attempt to optimize NOT (NOT(A)) back to A,
effectively removing the ring oscillator;
• A structural graph pattern searches the netlist for ring sub-graphs of this type.
Thus, the HTDS method developed by authors of [72] suggests that the lifecycle of
detection of various hardware Trojans introduced by intruders accompanies the entire
lengthy process of microcircuit development through various phases using the set of
rules depending on a specific phase (IC design stage) and obtained from the traditional
knowledge base. We can argue that this approach is actually an effective means
against attackers on design, synthesis, and partially against attackers on production
stage, since this lifecycle is applied only in the corresponding phases of circuit
development phases. However, this will not be effective against distribution Trojan
attacks, which are currently just as numerous.
Clearly, each of such embedded Trojans always leaves certain traces, or so-called
hints of its presence in various components of the created objects of the project. It is
necessary to understand that each such rule formulated in HTDS has only a certain
determined probability of detecting a specific Trojan based on this hint. The more
hints there are, or the earlier in the development the Trojan is inserted, the more
scans they are going to be subjected to. Therefore, the case where several Trojans
are embedded in a single IC is still fairly rare; moreover, this trend will leave even
more such hints, thus making detection of the Trojan even easier in a sense.
Another problem for Trojan hunters is represented by dual-use structures. As
noted above, a ring oscillator, as well as all the above patterns can be legitimately
used in microcircuits; therefore, all such structures identified during HTDS need to
be shown to the senior engineer for analysis.
The above example demonstrates why stricter rules are still more preferable: it is
better to create and subsequently identify various simulated mistakes (that are still
re-examined later) than to skip real mistakes that actually pose a threat to safety and
can remain in the sleeping mode throughout the entire detection process.
Of course, several words need to be said about limitations of this interesting
method of hardware Trojan identification.
Single yet extremely troublesome disadvantage of this HTDS method consists in
the fact that it depends a lot on the quality of verification, on formulated properties and
687
transmission lines. This extremely simple structure can be detected in several types
of Trojan implementation (for instance, side channels, independent synchronization,
or ambient temperature measurement). As is know, ring oscillators are also used
legitimately (e.g., random number generators and physical uncloneable functions).
However, since they are structures used in multiple examples of Trojans, they were
also included in the knowledge base in [72]. In order to detect such structures, many
rules can be invented. The work [72] contains the following rules aimed at reducing
the risk of using an embedded ring oscillator:
• In formal verification: a specific rule forbids substructures with outputs, but
without digital inputs;
• On source-code level: a rule reports the use of optimizing-inhibiting compiler- or
source-code flag (e.g., keep—i noprune—codes in the VHDL). In this specific
case, most synthesis means will attempt to optimize NOT (NOT(A)) back to A,
effectively removing the ring oscillator;
• A structural graph pattern searches the netlist for ring sub-graphs of this type.
Thus, the HTDS method developed by authors of [72] suggests that the lifecycle of
detection of various hardware Trojans introduced by intruders accompanies the entire
lengthy process of microcircuit development through various phases using the set of
rules depending on a specific phase (IC design stage) and obtained from the traditional
knowledge base. We can argue that this approach is actually an effective means
against attackers on design, synthesis, and partially against attackers on production
stage, since this lifecycle is applied only in the corresponding phases of circuit
development phases. However, this will not be effective against distribution Trojan
attacks, which are currently just as numerous.
Clearly, each of such embedded Trojans always leaves certain traces, or so-called
hints of its presence in various components of the created objects of the project. It is
necessary to understand that each such rule formulated in HTDS has only a certain
determined probability of detecting a specific Trojan based on this hint. The more
hints there are, or the earlier in the development the Trojan is inserted, the more
scans they are going to be subjected to. Therefore, the case where several Trojans
are embedded in a single IC is still fairly rare; moreover, this trend will leave even
more such hints, thus making detection of the Trojan even easier in a sense.
Another problem for Trojan hunters is represented by dual-use structures. As
noted above, a ring oscillator, as well as all the above patterns can be legitimately
used in microcircuits; therefore, all such structures identified during HTDS need to
be shown to the senior engineer for analysis.
The above example demonstrates why stricter rules are still more preferable: it is
better to create and subsequently identify various simulated mistakes (that are still
re-examined later) than to skip real mistakes that actually pose a threat to safety and
can remain in the sleeping mode throughout the entire detection process.
Of course, several words need to be said about limitations of this interesting
method of hardware Trojan identification.
Single yet extremely troublesome disadvantage of this HTDS method consists in
the fact that it depends a lot on the quality of verification, on formulated properties and