648
7 Countermeasures Against Hardware Trojans
As noted in works [2—3], the use of preventive measures and modern hardware Trojan detection methods cannot guarantee that the manufactured IC doesn’t
contain hardware implants. Great variety of associated security threats, as well as
huge state space for placement of hardware implants made developers of microcircuits and microcircuit-based systems with the issue of ensuring safe operation of
a system with infected ICs and, in particular, the task of preventing activation of
embedded Trojans. Such approach would allow using hardware, paying no attention
to the embedded hardware Trojans, and even using commercial-off-the-shelf (COTS)
electronic components to build hardware implant-resistant and reliable electronic
systems.
Most publications on countering hardware Trojans are dedicated to a single class
or subclass of threats. Clearly, security can be improved with the help of multilevel protection, in which every level is independently aimed at certain actions and
mechanisms of Trojan activation with subsequent integration of all these measures
into general strategy of protection.
Most suggested and experimentally verified countermeasure mechanisms can be
subdivided into the following large groups:
• data protection;
• new architectures on the register transmission level;
• reconfigurable architectures;
• replication, fragmentation, and voting strategies.
Data protection (including protection of processor commands) suggests prevention of activation of the hardware Trojan and/or blocking direct access of the Trojan
hardware to any sensitive data. Special protecting device needs to control the selection of data stored or transfered within an IC or between ICs and logical models of
the system, blocking the mechanism used by the Trojan for interaction with data.
The work [4] considers several methods of data protection with prevention of
activation of a knowingly implemented Trojan. Some of these methods were implemented on the standard Zesto × 86 simulator. Receipt of the activation code by the
hardware implant is prevented here by scrambling (encryption) of the information
channel (bus). It is applied to data processing blocks that are not directly involved in
calculations. The authors suggest using relatively simple trusted encryption schemes
to hide data (e.g., exclusive OR with pseudo-random numbers—Xorshif-encryption),
masking them only for a short period of time.
The effectiveness of such scrambling was researched by introducing a
parametrized delay in cache and the memory controller. Bus scrambling actually
prevented activation of simple Trojans; at the same time, it remained possible. For
example, if a simple 32-bit trigger is used, the activation will take 232 cycles.
Approach with a better control can be implemented by redefining all inputs into
fully functionally reliable space of states using trusted and stable encryption sphere.
Since such data obfuscation in computing blocks can lead to incorrect computations, in this case it is suggested to use homomorphic encryption [5], which allows
computing blocks to work directly with encrypted data. Encryption is determined as
homomorphic in terms of the computational function, and the computing unit will
7 Countermeasures Against Hardware Trojans
As noted in works [2—3], the use of preventive measures and modern hardware Trojan detection methods cannot guarantee that the manufactured IC doesn’t
contain hardware implants. Great variety of associated security threats, as well as
huge state space for placement of hardware implants made developers of microcircuits and microcircuit-based systems with the issue of ensuring safe operation of
a system with infected ICs and, in particular, the task of preventing activation of
embedded Trojans. Such approach would allow using hardware, paying no attention
to the embedded hardware Trojans, and even using commercial-off-the-shelf (COTS)
electronic components to build hardware implant-resistant and reliable electronic
systems.
Most publications on countering hardware Trojans are dedicated to a single class
or subclass of threats. Clearly, security can be improved with the help of multilevel protection, in which every level is independently aimed at certain actions and
mechanisms of Trojan activation with subsequent integration of all these measures
into general strategy of protection.
Most suggested and experimentally verified countermeasure mechanisms can be
subdivided into the following large groups:
• data protection;
• new architectures on the register transmission level;
• reconfigurable architectures;
• replication, fragmentation, and voting strategies.
Data protection (including protection of processor commands) suggests prevention of activation of the hardware Trojan and/or blocking direct access of the Trojan
hardware to any sensitive data. Special protecting device needs to control the selection of data stored or transfered within an IC or between ICs and logical models of
the system, blocking the mechanism used by the Trojan for interaction with data.
The work [4] considers several methods of data protection with prevention of
activation of a knowingly implemented Trojan. Some of these methods were implemented on the standard Zesto × 86 simulator. Receipt of the activation code by the
hardware implant is prevented here by scrambling (encryption) of the information
channel (bus). It is applied to data processing blocks that are not directly involved in
calculations. The authors suggest using relatively simple trusted encryption schemes
to hide data (e.g., exclusive OR with pseudo-random numbers—Xorshif-encryption),
masking them only for a short period of time.
The effectiveness of such scrambling was researched by introducing a
parametrized delay in cache and the memory controller. Bus scrambling actually
prevented activation of simple Trojans; at the same time, it remained possible. For
example, if a simple 32-bit trigger is used, the activation will take 232 cycles.
Approach with a better control can be implemented by redefining all inputs into
fully functionally reliable space of states using trusted and stable encryption sphere.
Since such data obfuscation in computing blocks can lead to incorrect computations, in this case it is suggested to use homomorphic encryption [5], which allows
computing blocks to work directly with encrypted data. Encryption is determined as
homomorphic in terms of the computational function, and the computing unit will