4.10 Techniques for Hardware Trojan Design
407
application software are making big profit. Software IP theft through hardwarecreated back doors poses a significant threat. This threat was confirmed by the
authors of work [244] who implemented six types of hardware Trojans which can
leak the software IP (the RC5 encryption program) through data outputs or to external
memory. They demonstrated the following specific examples.
Leak of software IP, payload #1: Leak of program at runtime through LED.
When an instruction is fetched from the instruction memory to the register, it is
also passed on to the LED ports for display. Sometimes the information leakage
channel can be temporarily unused output ports or various side channels.
Leak of software IP, payload #2: Leak of separate parts of software related to critical computing. For example, the program segment related to critical computing of
an encryption algorithm is implemented in functions or parts of program and used
multiple times in program. In such circumstances, the hardware Trojan payload
can be implemented to leak such functions or parts requiring only extra hardware
logic to identify the starting and end point of program. In the quoted work, the
hardware Trojan identifies lcall and ret instructions to obtain the program part
required by the intruder.
Leak of software IP, payload #3: Here the secret information is stored during
the program execution but it is stolen during delay loops. Leaking information at
runtime might be noticed by the user because any output may be closely monitored
for security purposes. Alternatively, the intruder can secretly store a copy of the
executed instructions into idle memory locations and leak them during the delay
loops of the program. Actually often the delay loops could be for waiting for the
next information transaction, and sometimes it occurs during the gap between
one encryption and the next plaintext. In these cases, the output values might be
neglected by the user and can be used by the attacker.
Apart from Trojan payload of leaking the software IP, the authors [244] also
implemented hardware Trojans to leak the encryption key, which is central to the
confidentiality of an encryption system. In the RC5 algorithm, the encryption key is
used in bytes to XOR with the plaintext or intermediate values, where the XOR is
actually realized through ADD or ADDC instruction. Therefore, the hardware Trojan
is implemented in such a way that when it is triggered, there is a leak of operation
components. In particular, two versions of the Trojan are implemented to leak the key
through primary outputs and the external memory for anytime access, respectively.
The hardware Trojans can cause different system malfunctions. Let us briefly run
through the nature of malfunctions caused by different payloads.
Malfunction caused by payload #1: Leads to recording of “illegal” (incorrect)
information in the memory.
Malfunction caused by payload #2: Leads to modification of the stack pointer to
change the return address from the subroutine.
Malfunction caused by payload #3: Causes an unauthorized key change at the
ALU input.
407
application software are making big profit. Software IP theft through hardwarecreated back doors poses a significant threat. This threat was confirmed by the
authors of work [244] who implemented six types of hardware Trojans which can
leak the software IP (the RC5 encryption program) through data outputs or to external
memory. They demonstrated the following specific examples.
Leak of software IP, payload #1: Leak of program at runtime through LED.
When an instruction is fetched from the instruction memory to the register, it is
also passed on to the LED ports for display. Sometimes the information leakage
channel can be temporarily unused output ports or various side channels.
Leak of software IP, payload #2: Leak of separate parts of software related to critical computing. For example, the program segment related to critical computing of
an encryption algorithm is implemented in functions or parts of program and used
multiple times in program. In such circumstances, the hardware Trojan payload
can be implemented to leak such functions or parts requiring only extra hardware
logic to identify the starting and end point of program. In the quoted work, the
hardware Trojan identifies lcall and ret instructions to obtain the program part
required by the intruder.
Leak of software IP, payload #3: Here the secret information is stored during
the program execution but it is stolen during delay loops. Leaking information at
runtime might be noticed by the user because any output may be closely monitored
for security purposes. Alternatively, the intruder can secretly store a copy of the
executed instructions into idle memory locations and leak them during the delay
loops of the program. Actually often the delay loops could be for waiting for the
next information transaction, and sometimes it occurs during the gap between
one encryption and the next plaintext. In these cases, the output values might be
neglected by the user and can be used by the attacker.
Apart from Trojan payload of leaking the software IP, the authors [244] also
implemented hardware Trojans to leak the encryption key, which is central to the
confidentiality of an encryption system. In the RC5 algorithm, the encryption key is
used in bytes to XOR with the plaintext or intermediate values, where the XOR is
actually realized through ADD or ADDC instruction. Therefore, the hardware Trojan
is implemented in such a way that when it is triggered, there is a leak of operation
components. In particular, two versions of the Trojan are implemented to leak the key
through primary outputs and the external memory for anytime access, respectively.
The hardware Trojans can cause different system malfunctions. Let us briefly run
through the nature of malfunctions caused by different payloads.
Malfunction caused by payload #1: Leads to recording of “illegal” (incorrect)
information in the memory.
Malfunction caused by payload #2: Leads to modification of the stack pointer to
change the return address from the subroutine.
Malfunction caused by payload #3: Causes an unauthorized key change at the
ALU input.