4.11 Analytical Review of Basic Techniques …
431
While the importance of security assurance of commercial off-the-shelf components has increased significantly, few researchers deal with this issue, as shown in
Table 4.9 [259]. One approach, called SAFER PATH, attempts to achieve security
of the computing system when multiple processing elements simultaneously permit
to execute a computer program [312]. Rather than development and use of single
trusted processor, these authors offer to use a certain quantity of untrusted commercial
off-the-shelf processors with a small subset of trusted logic. Then this combination
can be used as a trusted processor with protection against the effects of hardware
Trojans. This approach greatly simplifies the certification process and allows to take
advantage of the most advanced commercial off-the-shelf components. However,
this technique has a few limitations [259]:
(1) It requires certain physical variability of processor elements to avoid the possibility of inserting the same or colluding hardware Trojans. This can be achieved
by utilizing the unique register transfer level descriptions of the same specifications of processor elements which are created by independent developers
using different sets of design tools. Such chips with various descriptions can
be fabricated at different foundries, utilizing different processes, geometries,
and cell libraries. It is very difficult to meet this requirement for untraceable
commercial off-the-shelf components.
(2) The method provides protection only for processor (processing) elements. It
does not protect other system elements such as memory and data bus from
hardware Trojan attacks. Efficient and comprehensive solutions to authenticate commercial off-the-shelf and/or achieve secure operations using such
components are therefore still needed.
4.11.5.2 Hardware Trojan Detection Without Golden Model
Almost all the Trojan detection techniques rely on the existence of the golden model.
Typically, there are two kinds of golden models required for the existing detection
methods: golden design or golden IC. Generally, golden designs are needed for
presilicon Trojan detection approaches to validate RTL/netlist of IP-cores or SoC
designs. To verify and authenticate the third-party IP-cores, a golden functionality or
features should be available. Moreover, a portion of postsilicon detection approaches
are able to detect hardware Trojans based on the existence of golden designs (either at
gate or layout levels). The method of destructive reverse engineering needs a golden
netlist or topological layout for the comparison. Functional tests also need golden
designs to generate test patterns and correct responses. The possibility of obtaining
a golden design is dependent on three factors: IP-core supplier, SoC developer, and
third-party development tools they use. Except for model B, all other threat models
(A, C, D, E, F, and G) contain untrusted parties that are involved in the design
development procedure. Having a golden design available is therefore very unrealistic
in most scenarios. On the other hand, since SoC developers are trusted in models
A and F, they can produce a golden SoC design only when third-party IP-cores
are trusted or can be verified. If the SoC developer is untrusted, it is theoretically
431
While the importance of security assurance of commercial off-the-shelf components has increased significantly, few researchers deal with this issue, as shown in
Table 4.9 [259]. One approach, called SAFER PATH, attempts to achieve security
of the computing system when multiple processing elements simultaneously permit
to execute a computer program [312]. Rather than development and use of single
trusted processor, these authors offer to use a certain quantity of untrusted commercial
off-the-shelf processors with a small subset of trusted logic. Then this combination
can be used as a trusted processor with protection against the effects of hardware
Trojans. This approach greatly simplifies the certification process and allows to take
advantage of the most advanced commercial off-the-shelf components. However,
this technique has a few limitations [259]:
(1) It requires certain physical variability of processor elements to avoid the possibility of inserting the same or colluding hardware Trojans. This can be achieved
by utilizing the unique register transfer level descriptions of the same specifications of processor elements which are created by independent developers
using different sets of design tools. Such chips with various descriptions can
be fabricated at different foundries, utilizing different processes, geometries,
and cell libraries. It is very difficult to meet this requirement for untraceable
commercial off-the-shelf components.
(2) The method provides protection only for processor (processing) elements. It
does not protect other system elements such as memory and data bus from
hardware Trojan attacks. Efficient and comprehensive solutions to authenticate commercial off-the-shelf and/or achieve secure operations using such
components are therefore still needed.
4.11.5.2 Hardware Trojan Detection Without Golden Model
Almost all the Trojan detection techniques rely on the existence of the golden model.
Typically, there are two kinds of golden models required for the existing detection
methods: golden design or golden IC. Generally, golden designs are needed for
presilicon Trojan detection approaches to validate RTL/netlist of IP-cores or SoC
designs. To verify and authenticate the third-party IP-cores, a golden functionality or
features should be available. Moreover, a portion of postsilicon detection approaches
are able to detect hardware Trojans based on the existence of golden designs (either at
gate or layout levels). The method of destructive reverse engineering needs a golden
netlist or topological layout for the comparison. Functional tests also need golden
designs to generate test patterns and correct responses. The possibility of obtaining
a golden design is dependent on three factors: IP-core supplier, SoC developer, and
third-party development tools they use. Except for model B, all other threat models
(A, C, D, E, F, and G) contain untrusted parties that are involved in the design
development procedure. Having a golden design available is therefore very unrealistic
in most scenarios. On the other hand, since SoC developers are trusted in models
A and F, they can produce a golden SoC design only when third-party IP-cores
are trusted or can be verified. If the SoC developer is untrusted, it is theoretically