4.10 Techniques for Hardware Trojan Design
405
can activate an embedded “sleeping” Trojan if they fulfill the condition required for its
activation. For a processor running an operating system with multiple user programs,
the hardware Trojan trigger condition design can be applied in multiple ways, where
all three methods listed above can be used by the Trojan trigger mechanism. For
example, the 8051 embedded microcontroller can run a dedicated program to perform
RC5 encryption [250]. In this case, Trojan trigger conditions should be capable of
being exploited by this specific program. Of course, it is necessary to make sure the
trigger condition is only known and controllable by the attacker and it should not
be triggered during normal operation of the program. Therefore, it’s not possible to
simply use a sequence of instructions as the trigger condition. Instead, it’s possible
to use: (1) specific sequence of data (plaintext in this case) and (2) specific sequence
of combinations of specific instructions/data. In particular, the authors [244] use a
specific sequence of instructions to capture a sequence of plaintext data, which is then
compared with the pre-defined plaintext sequence to determine whether to trigger
the Trojan or not (see Fig. 4.63).
The authors embedded an FSM serving as a sequence monitor in the control logic
of the 8051 microcontroller to watch for the execution of the following code segment
to capture the plaintext:
MOVX A, dptr
ADDC A, Ri MOV
Ri, A
Based on analysis of the RC5 encryption algorithm, the authors find that the algorithm will start with XOR operation of the plaintext stored in the internal memory,
with the encryption key stored in the external memory (Fig. 4.63a). Repetition of
the above code segment allows the FSM to capture the plaintext, namely, the data
from external memory upon observation of such code segment. This means the data
is captured in the arithmetic logic unit (ALU) inputs instead from the data bus. This
is more reliable than directly monitoring the data on the data bus. Upon capturing
each plaintext word, a comparison will be performed with the pre-defined word to
decide whether to move forward one state or reinitialize the sequence monitor. If the
entire sequence of the pre-defined plaintext is seen, the FSM will trigger the Trojan
payload (Fig. 4.63b).
The length of the plaintext sequence needs to trade-off between the requirement
of a low probability of accidental trigger during testing and the hardware overhead.
Since the 8051 microcontroller has a multi-cycle microarchitecture using an FSM
to control the instruction execution, the attacker can easily embed a Trojan trigger
sequence monitor into the control logic.
Hardware Trojan payload
Regarding the function of the Trojan payload, various technical solutions have been
proposed in the literature starting from simply inverting at some internal node,
presenting non-sense information at the input buses, to carefully thought-out ways
of secret information leaking inside the hardware. Here, leaking information channels can be output ports, modulation of existing outgoing information, or the carrier
405
can activate an embedded “sleeping” Trojan if they fulfill the condition required for its
activation. For a processor running an operating system with multiple user programs,
the hardware Trojan trigger condition design can be applied in multiple ways, where
all three methods listed above can be used by the Trojan trigger mechanism. For
example, the 8051 embedded microcontroller can run a dedicated program to perform
RC5 encryption [250]. In this case, Trojan trigger conditions should be capable of
being exploited by this specific program. Of course, it is necessary to make sure the
trigger condition is only known and controllable by the attacker and it should not
be triggered during normal operation of the program. Therefore, it’s not possible to
simply use a sequence of instructions as the trigger condition. Instead, it’s possible
to use: (1) specific sequence of data (plaintext in this case) and (2) specific sequence
of combinations of specific instructions/data. In particular, the authors [244] use a
specific sequence of instructions to capture a sequence of plaintext data, which is then
compared with the pre-defined plaintext sequence to determine whether to trigger
the Trojan or not (see Fig. 4.63).
The authors embedded an FSM serving as a sequence monitor in the control logic
of the 8051 microcontroller to watch for the execution of the following code segment
to capture the plaintext:
MOVX A, dptr
ADDC A, Ri MOV
Ri, A
Based on analysis of the RC5 encryption algorithm, the authors find that the algorithm will start with XOR operation of the plaintext stored in the internal memory,
with the encryption key stored in the external memory (Fig. 4.63a). Repetition of
the above code segment allows the FSM to capture the plaintext, namely, the data
from external memory upon observation of such code segment. This means the data
is captured in the arithmetic logic unit (ALU) inputs instead from the data bus. This
is more reliable than directly monitoring the data on the data bus. Upon capturing
each plaintext word, a comparison will be performed with the pre-defined word to
decide whether to move forward one state or reinitialize the sequence monitor. If the
entire sequence of the pre-defined plaintext is seen, the FSM will trigger the Trojan
payload (Fig. 4.63b).
The length of the plaintext sequence needs to trade-off between the requirement
of a low probability of accidental trigger during testing and the hardware overhead.
Since the 8051 microcontroller has a multi-cycle microarchitecture using an FSM
to control the instruction execution, the attacker can easily embed a Trojan trigger
sequence monitor into the control logic.
Hardware Trojan payload
Regarding the function of the Trojan payload, various technical solutions have been
proposed in the literature starting from simply inverting at some internal node,
presenting non-sense information at the input buses, to carefully thought-out ways
of secret information leaking inside the hardware. Here, leaking information channels can be output ports, modulation of existing outgoing information, or the carrier