4.10 Techniques for Hardware Trojan Design
409
Fig. 4.64 The strict order of creating macros for the FPGA platform [255]
4.10.2 Examples of Designing Hardware Trojans Using
Additional Gates
In literature [244, 253, 254], the Trojan detection approaches based on ring oscillator network (RON) were proposed for hardware Trojan detection through ring
oscillator (RO) frequency change. These RON-based approaches mainly fall into
two categories: one approach is securing the design by dynamically configuring
circuit paths into RO to monitor undesired design modification [255] and the other
approach is additionally inserted RON to detect voltage drops due to extra Trojan
circuitry [253]. We consider below the designs secured by the first approach and
analyze the effectiveness of the proposed Trojan insertions in both FPGA and ASIC
scenarios. The attackers can insert stealthy Trojans which successfully evade the
security mechanisms.
In an FPGA-based framework, the insertion of any extra circuitry would cause
the entire design to be re-synthesized and re-routed, resulting in wide fluctuations
in embedded RO frequencies, which were dominated by interconnect delays. An
effective Trojan insertion technique is to preserve the original design topology by
making it a Hard Macro [251]. Hard Macro generally refers to a pre-compiled module,
which can be reused in its optimized form. Figure 4.65 illustrates the flow of creating
a Hard Macro using Xilinx ISE [256]. Since a Hard Macro consists of previously
synthesized, mapped, placed, and routed circuitry, the RO layout will not change due
to Trojan insertion.
Of course, having set a task to intrude in ASIC, a clever attacker can reverse
engineer and bypass existing embedded ROs when mounting his hardware Trojans.
Even if all paths (and all gates) of the circuit are covered by relevant RO, the hardware
Trojan can still be inserted without significant impact on the delay as shown below.
Generally, Trojan trigger logic only adds load capacitance to some circuit nodes,
which can be distributed to different ROs. On the other hand, Trojan payload usually
adds an (XOR) gate delay to the original circuit path, as shown in Fig. 4.65a. Any of
four ways of designing Trojan payload helps to avoid directly inserting gates in the
critical path of RO. Let us take a brief look at these methods.
409
Fig. 4.64 The strict order of creating macros for the FPGA platform [255]
4.10.2 Examples of Designing Hardware Trojans Using
Additional Gates
In literature [244, 253, 254], the Trojan detection approaches based on ring oscillator network (RON) were proposed for hardware Trojan detection through ring
oscillator (RO) frequency change. These RON-based approaches mainly fall into
two categories: one approach is securing the design by dynamically configuring
circuit paths into RO to monitor undesired design modification [255] and the other
approach is additionally inserted RON to detect voltage drops due to extra Trojan
circuitry [253]. We consider below the designs secured by the first approach and
analyze the effectiveness of the proposed Trojan insertions in both FPGA and ASIC
scenarios. The attackers can insert stealthy Trojans which successfully evade the
security mechanisms.
In an FPGA-based framework, the insertion of any extra circuitry would cause
the entire design to be re-synthesized and re-routed, resulting in wide fluctuations
in embedded RO frequencies, which were dominated by interconnect delays. An
effective Trojan insertion technique is to preserve the original design topology by
making it a Hard Macro [251]. Hard Macro generally refers to a pre-compiled module,
which can be reused in its optimized form. Figure 4.65 illustrates the flow of creating
a Hard Macro using Xilinx ISE [256]. Since a Hard Macro consists of previously
synthesized, mapped, placed, and routed circuitry, the RO layout will not change due
to Trojan insertion.
Of course, having set a task to intrude in ASIC, a clever attacker can reverse
engineer and bypass existing embedded ROs when mounting his hardware Trojans.
Even if all paths (and all gates) of the circuit are covered by relevant RO, the hardware
Trojan can still be inserted without significant impact on the delay as shown below.
Generally, Trojan trigger logic only adds load capacitance to some circuit nodes,
which can be distributed to different ROs. On the other hand, Trojan payload usually
adds an (XOR) gate delay to the original circuit path, as shown in Fig. 4.65a. Any of
four ways of designing Trojan payload helps to avoid directly inserting gates in the
critical path of RO. Let us take a brief look at these methods.