Stealthy dopant-level hardware Trojans: Extended version

Abstract

In recent years, hardware Trojans have drawn the attention of governments and industry as well as the scientific community. One of the main concerns is that integrated circuits, e.g., for military or critical-infrastructure applications, could be maliciously manipulated during the manufacturing process, which often takes place abroad. However, since there have been no reported hardware Trojans in practice yet, little is known about how such a Trojan would look like and how difficult it would be in practice to implement one. In this paper we propose an extremely stealthy approach for implementing hardware Trojans below the gate level, and we evaluate their impact on the security of the target device. Instead of adding additional circuitry to the target design, we insert our hardware Trojans by changing the dopant polarity of existing transistors. Since the modified circuit appears legitimate on all wiring layers (including all metal and polysilicon), our family of Trojans is resistant to most detection techniques, including fine-grain optical inspection and checking against “golden chips”. We demonstrate the effectiveness of our approach by inserting Trojans into two designs—a digital post-processing derived from Intel’s cryptographically secure RNG design used in the Ivy Bridge processors and a side-channel resistant SBox implementation—and by exploring their detectability and their effects on security.

Full text

Noname manuscript No.
(will be inserted by the editor)
Stealthy Dopant-Level Hardware Trojans: Extended
Version
Georg T. Becker1, Francesco Regazzoni2, Christof Paar1, 3,
and Wayne P. Burleson1
the date of receipt and acceptance should be inserted later
Abstract In recent years, hardware Trojans have drawn
the attention of governments and industry as well as
the scientific community. One of the main concerns is
that integrated circuits, e.g., for military or critical-
infrastructure applications, could be maliciously ma-
nipulated during the manufacturing process, which of-
ten takes place abroad. However, since there have been
no reported hardware Trojans in practice yet, little is
known about how such a Trojan would look like, and
how difficult it would be in practice to implement one.
In this paper we propose an extremely stealthy ap-
proach for implementing hardware Trojans below the
gate level, and we evaluate their impact on the security
of the target device. Instead of adding additional cir-
cuitry to the target design, we insert our hardware Tro-
jans by changing the dopant polarity of existing tran-
sistors. Since the modified circuit appears legitimate
on all wiring layers (including all metal and polysili-
con), our family of Trojans is resistant to most detec-
tion techniques, including fine-grain optical inspection
and checking against “golden chips”. We demonstrate
the effectiveness of our approach by inserting Trojans
into two designs — a digital post-processing derived
from Intel’s cryptographically secure RNG design used
in the Ivy Bridge processors and a side-channel resis-
tant SBox implementation — and by exploring their
detectability and their effects on security.
The authors would like to thank Mario Kirschbaum from TU
Graz for his helpful comments in implemeting iMDPL. This
work was supported in part by the NSF Grants 0916854,
0923313 and 0964641 and by the HHS Grant 90TR0003/01.
1University of Massachusetts Amherst, USA
2ALaRI - University of Lugano, Switzerland
3Horst G¨ortz Institut for IT-Security, Ruhr-Universit¨at
Bochum, Germany
Keywords Hardware Trojans, malicious hardware, lay-
out modifications, Trojan side-channel
1 Introduction
Integrated circuits (ICs) are the heart of virtually all
modern applications. This includes sensitive and safety
critical devices, such as medical devices, automotive, in-
dustrial control systems, power management or military
devices. Often circuit blocks in a single IC are designed
by different parties, manufactured by an external and
possibly off-shore foundry, packaged by a separate com-
pany and supplied by an independent distributor.
This increased exploitation of out-sourcing and ag-
gressive use of globalization in circuit manufacturing
has given rise to several trust and security issues, as
each of the parties involved potentially constitutes a
security risk. In 2005 the Defense Science Board of the
US Department of Defense published a report in which
it publicly voiced its concern about US military reliance
on ICs manufactured abroad [4]. One threat in this
context is that malicious modifications, also referred
to as hardware Trojans, could be introduced during
manufacturing. All this raises the question of trust in
the final chip, especially if chips for military or safety-
critical civilian applications are involved. Even if chips
are manufactured in a trusted fab, there is the risk
that chips with hardware Trojans could be introduced
into the supply chain. The discovery of counterfeit chips
in industrial and military products over the last years
has made this threat much more conceivable. For in-
stance, in 2010 the chip broker VisionTech was charged
with selling fake chips, many of which were destined
for safety and security critical systems such as high-
speed train breaks, hostile radar tracking in F-16 fighter

jets, and ballistic missile control systems [6]. The threat
of hardware Trojans is expected to only increase with
time, especially with the recent concerns about cyber-
war, cf., e.g., [13,20].
Surprisingly, despite the major research efforts in
the general area of hardware Trojans, little is known
about how to built stealthy hardware Trojans at the
layout level (post place&route). Contrary to the ma-
jority of past works, in this paper, we investigate a new
family of Trojans that do not need any extra logic re-
sources but merely require a change in the dopant po-
larity of a few transistors. Hence, these Trojans add
zero overhead in terms of additional transistors and
metal wires. We show that such a change will not be
detected by several of the common Trojan testing meth-
ods, including optical inspection. A central question
that arises is how such minuscule manipulations can
result in changes to the target system which are mean-
ingful to an attacker. We address this question using
two case studies. First, we show an attack against a de-
sign derived from Intel’s RNG design used in the Ivy
Bridge processors, and second, a dopant Trojan that
allows attacking a side-channel resistant SBox imple-
mentation. Since the hardware is usually the root of
trust in a system, even small malicious modifications of
the hardware can be devastating to system security.
1.1 Related work
Research efforts targeting hardware Trojans can be di-
vided into two parts, one related to the design and the
implementation of hardware Trojans, and one address-
ing the problem of detecting hardware Trojans. In this
section we summarize some contributions from both ar-
eas.
1.1.1 Hardware Trojan designs
There have been relatively few research reports address-
ing the question of creating (as opposed to defeating)
hardware Trojans, with the first hardware Trojans pub-
lished around 2008. Most proposed hardware Trojans
consist of small to mid-size circuits which are added
at the HDL level. For example, King et al. [10] pre-
sented a hardware Trojan inserted into a CPU that
was capable of granting complete control of the sys-
tem to an external attacker. The attacker can make
arbitrary changes to the program code and can get un-
limited access to the memory by simply sending a spe-
cific malicious UDP package to the processor. This Tro-
jan shows how vulnerable systems can become once the
root of trust — the hardware — is compromised. An-
other class of HDL-level Trojans are those which cre-
ate a hidden side-channel to leak out secret keys by
adding only a few additional gates [12]. Perhaps most
of the Trojans proposed so far were shown at the annual
hardware Trojan challenge hosted by NYU-Poly, where
students insert hardware Trojans into a target FPGA
design with the goal of overcoming hardware detection
mechanisms [18].
All these Trojans have in common that they are in-
serted at the HDL level. The attack scenario here is
that malicious circuitry is introduced into the design
flow of the IC. However, these Trojans are difficult to
realize by a malicious foundry which usually only has
access to the layout masks. In this context, finding the
needed space and adding extra connections to place &
route the Trojan gates can be impractical. Furthermore,
adding additional gates to the design after place & route
can easily be detected using optical reverse-engineering.
How realistic these Trojans are in a foundry-based at-
tack model is therefore still unanswered.
A more realistic scenario for a foundry-based Trojan
insertion are malicious modifications carried out at the
layout level. An example of such a Trojan is the Trojan
proposed by Shiyanovskii et.al. [21]. In this work the
dopant concentration is changed in order to increase the
effects of aging on the circuit, with the ultimate goal of
reducing the expected lifetime of the device. However,
these Trojans have limited usability, since it is hard to
predict the exact time the ICs will fail and they can
usually only serve as a denial-of-service type of Trojan.
1.1.2 Hardware Trojan detection
Hardware Trojan detection mechanisms can be divided
into post-manufacturing and pre-manufacturing detec-
tion mechanisms. The input to pre-manufacturing Tro-
jan detection is usually the gate netlist or HDL descrip-
tion of the design under test. Pre-manufacturing Trojan
detection tries to detect Trojans that have been inserted
at the HDL level into the design flow, e.g. by third
party IPs, design tools or untrusted employees. Usu-
ally the Trojan detection is based on functional testing
or formal verification. There have also been proposals
of how to defend against rather than detect hardware
Trojans at the HDL level. One approach is to replace
part of the hardware design that was not covered by
functional testing with software [8]. Another approach
is to add redundancy or a control circuitry between
untrusted IPs that will make Trojan activation based
on counters and inputs difficult [23]. However, these
proposed Trojan detection and prevention mechanisms
cannot prevent Trojans inserted at the sub-gate level,
including the ones proposed in this paper.

Post-manufacturing Trojan detection mechanisms pri-
marily attempt to detect Trojans inserted during man-
ufacturing. They can be divided into two categories
based on whether or not they need a “golden chip” (also
referred to as golden model). A golden chip is a chip
which is known to not include malicious modifications.
The standard approach proposed to detect layout-level
hardware Trojans and to find a golden chip is the use
of optical reverse-engineering. The idea is to decap the
suspected chip and make photos of each layer of the
chip with e.g. a scanning electron microscope (SEM).
These photos are then compared to the layout mask to
detect additional metal or polysilicon wires. Additional
metal wires and transistors can usually be detected very
reliably. However, the overall process is expensive, time
consuming and also destroys the chip under test. Hence,
this method can only be used on a small number of
chips. Also, optical reverse-engineering does not usually
allow to detect changes made to the dopant, especially
in small technologies. A dedicated setup could even-
tually allow to identify the dopant polarity. However,
doing so in a large design comprising millions of tran-
sistors implemented with small technologies seems im-
practical and represents an interesting future research
direction. We exploit this limitation to make our Tro-
jans resistant against optical reverse-engineering.
A different approach to test for hardware Trojans
without a golden chip is functional testing of the chip.
Functional testing is standard procedure in the IC de-
sign flow and to some degree will always be performed.
However, detecting Trojans is different from detecting
manufacturing defects. Creating efficient test cases for
hardware Trojan detection is difficult since the tester
does not know how the Trojan gates look like. As a
result, these Trojan gates are not taken into account
during the test case generation which usually tries to
optimize gate coverage. This leads to an inefficient func-
tional testing procedure in contrast to functional testing
at the netlist level, since in this case the Trojan gates
will be part of the input to the test case algorithms.
Trojan detection mechanisms that require a golden
chip are usually based on comparing side-channel infor-
mation of the golden chip and the suspected chip. The
most popular method is using the power side-channel
for Trojan detection [1] but other side-channels such
as time [11,25], electro-magnetics(EM) and heat have
been proposed as well. Typically these detection mech-
anisms can only detect Trojans that are at most three
to four orders of magnitude smaller than the target de-
sign [1]. Small Trojans on the other hand are likely to
stay undetected. Another approach to detect Trojans is
to add specific Trojan detection circuitry into the de-
sign that can detect if the design was changed during
manufacturing. For example, Rajendran et.al. [19] pro-
posed to add additional gates that transform parts of
the design into ring-oscillators. During testing, the fre-
quencies of these ring-oscillators are compared with a
golden chip to detect if the design was changed. These
methods usually require a golden chip to determine the
expected output of the detection circuitry, since cir-
cuit simulations are often not accurate enough. One
big disadvantage of Trojan detection circuitry is that
the circuitry itself can be subject to Trojan modifica-
tions. For similar reasons, the build-in-self-tests (BIST)
that are employed in some designs to automatically de-
tect manufacturing and aging defects, are of limited use
when applied to Trojan detection. This is not only due
to the fact that a Trojan can be inserted into the BIST
itself but also because the Trojan can be designed to
not trigger the BIST, since BISTs are usually designed
to only detect a sub-set of all possible errors.
1.2 Our goal and contribution
One of the major concerns are Trojans inserted during
manufacturing e.g. by an untrusted foundry, but most
of the published hardware Trojans are implemented at
the HDL level. In this paper, we will therefore focus on
Trojans inserted into designs at the layout level, after
the place & route phase. We concentrate on construct-
ing Trojans that can easily be added by a foundry and
that defeat Trojan detection mechanisms. Especially,
we propose layout-level hardware Trojans that can re-
sist optical inspection, which is believed to be a reliable
way to detect layout-level hardware Trojans. The pro-
posed Trojans are inserted by modifying only the polar-
ity of dopant in the active area and are therefore very
close to invisible to optical reverse-engineering. From
a technical point of view, such modifications are cer-
tainly feasible in practice: A very similar approach is
already used commercially for hardware-obfuscation in
which optical reverse-engineering needs to be defeated
as well [22]. By using two case studies, a side-channel re-
sistant SBox implementation and an implementation of
a secure digital random number post-processing design
derived from Intel’s new RNG used in the Ivy Bridge
processors, we prove that the proposed dopant-based
Trojans can be used efficiently in practice to compro-
mise the security of the underlying target design. To
the best of our knowledge, our dopant-based Trojans
are the first proposed, implemented, tested, and eval-
uated layout-level hardware Trojans that can do more
than act as denial-of-service Trojans based on aging ef-
fects.
The remainder of the paper is organized as followed.
In the next section we will introduce the basic concept

of our dopant-based Trojans. In Section 3, the first case
study, a Trojan inserted into a design derived from In-
tel’s new RNG design, is discussed. The second case
study is presented in Section 4, showing how a side-
channel resistant SBox implementation can be modified
to establish a hidden side-channel using the dopant Tro-
jans. In the last section the results are summarized and
conclusions are drawn.
2 Dopant-Trojans
In this section an efficient way to design hardware Tro-
jans without changing any metal or polysilicon layer of
the target design is introduced. The main idea of the
proposed Trojan is as follows: A gate of the original de-
sign is modified by applying a different dopant polarity
to specific parts of the gate’s active area. These modifi-
cations change the behavior of the target gate in a pre-
dictable way and are very similar to the technique used
for code-obfuscation in some commercial designs [22].
Using a simple inverter as an example, we explain these
dopant modifications by changing the behavior of the
target inverter gate in a way that it always outputs
VDD . However, the proposed techniques are sufficiently
general to be applied to other types of gates in a similar
way.
An inverter consists of a p-MOS and an n-MOS
transistor whose drain contacts are connected via a
metal layer as shown in Figure 1(a). The upper part of
Figure 1(a) shows a p-MOS transistor, whose cross sec-
tion is depicted on the left side of Figure 2(a). As it can
be seen, a p-MOS transistor consists of an n-well, the
positively doped source and drain region and the gate
region. The active area defines the area in which the
dopant masks apply and hence also defines the source
and drain area of the transistor. The polysilicon wire
defines the gate area of the transistor1.
To create an inverter Trojan that constantly out-
puts VDD , the positively doped p-dopant mask of this p-
MOS transistor is exchanged with the negatively doped
n-dopant mask. This change can be seen in the right
part of Figure 2(a), which depicts the cross section of a
Trojan p-MOS transistor. Doping an active area within
an n-well with n-dopant basically creates a connection
to the n-well. N-wells are usually always connected to
VDD in a CMOS design. Since the n-dopant is applied to
the entire active area of the p-MOS transistor, includ-
ing the metal contacts, a direct connection from these
contacts to the n-well is created. From Figure 2(a), it
1The silicon area below the polysilicon wire is not subject
to the dopant mask and hence remains the same polarity as
the underlying well.
(a) Original (b) Trojan
Fig. 1 Figure of an unmodified inverter gate (a) and of a
Trojan inverter gate with a constant output of VDD (b).
can be noticed that the source contact, which is con-
nected to VDD , has been transformed into an n-well
tap, creating an additional connection from the n-well
to VDD . The drain contact is also connected to the n-
well and thereby to VDD. Hence, we have created a
constant connection between VDD and the drain con-
tact without modifying the metal, polysilicon, n-well or
active area. The upper part of Figure 1(b) shows the
layout of the resulting p-MOS transistor Trojan.
In the second step the connection between the n-
MOS transistor’s drain contact and GND is constantly
disabled. This is achieved by applying p-dopant to the
source contact of the n-MOS transistor while leaving
the drain contact untouched. Applying p-dopant to the
source contact of the n-MOS transistor transforms it
into a well tap again and cuts of any connection between
the source contact and the negatively doped source area
of the n-MOS transistor. Therefore, the n-MOS transis-
tor is no longer connected to GND regardless of its gate
input. The cross section of the original and the Trojan
inverter are depicted on the left and on the right part
of Figure 2(b), while the layout can be seen in Figure
1(b). The metal, polysilicon, active and well layers are
identical with the original inverter in Figure 1(a), but
the Trojan gate always outputs VDD regardless of its
input.
Besides fixing the output of transistors to specific
values, it is also possible to change the strength of tran-
sistors in a similar way. The strength of a transistor in
CMOS is defined by its width. Usually the entire active
area of a transistor is doped and therefore the width
of a transistor is defined by the active area. However,
by decreasing the area which is doped positively in a
p-MOS transistor, it is possible to reduce the effective
width of the transistor. Hence, to decrease the strength
of a transistor it is sufficient to apply p-dopant to an
area smaller than the active area of the transistor.

(a) p-MOS Transistor (b) n-MOS Transistor
Fig. 2 Figure of an unmodifed p-MOS Transistor and Trojan p-MOS (a) transistor as well as of an n-MOS Transistor and
Trojan n-MOS transistor (b).
We want to stress that one of the major advan-
tages of the proposed dopant Trojan is that they can-
not be detected using state of the art optical reverse-
engineering since we only modify the dopant masks.The
introduced Trojans are similar to the commercially de-
ployed code-obfuscation methods [22] which also uses
different dopant polarity to prevent optical reverse en-
gineering. This suggests that our dopant Trojans are
extremely stealthy as well as practically feasible.
3 Case-study 1: Intel’s Ivy Bridge RNG
In this section we apply the concepts of our dopant Tro-
jans to a meaningful, high-profile target to demonstrate
the danger and practicability of the proposed Trojans.
Our first target is a design based on Intel’s new crypto-
graphically secure RNG. Most prominently, it is used in
the Ivy Bridge processors but will most likely be used in
many more designs in the future. We chose this target
because of its potential for real-world impact and be-
cause there is detailed information available about the
design and especially the way it is tested [7,9, 24].
The cryptographically secure RNG generates un-
predictable 128-bit random numbers. The security has
been verified by an independent security company [7]
and is NIST SP800-90, FIPS 140-2, and ANSI X9.82
compliant. We will modify the digital post-processing
of the design at the sub-transistor level to compromise
the security of keys generated with this RNG. Our Tro-
jan is capable of reducing the security of the produced
random number from 128 bits to nbits, where ncan
be chosen. Despite these changes, the modified Trojan
RNG passes not only the Built-In-Self-Test (BIST) but
also generates random numbers that pass the NIST test
suite for random numbers.
In the following section we first summarize the de-
sign of Intel’s RNG and then discuss our malicious mod-
ifications.
3.1 Intel’s TRNG design
Like most modern RNGs, Intel’s RNG design consists of
an entropy source (ES) and digital post-processing. The
design also features a Built-In-Self-Test (BIST) unit
that checks, at each power up, the correct functioning
of the entropy source and the digital post-processing.
The ES is a metastable circuit based on two cross
coupled inverters with adaptive feedback. The digital
post-processing consists of a Online Health Test (OHT)
unit and a cryptographically secure Deterministic Ran-
dom Bit Generator (DRBG). The OHT monitors the
random numbers from the entropy source to ensure that
the random numbers have a minimum entropy.
The Deterministic Random Bit Generator itself con-
sists of two parts, a conditioner and a rate matcher. The
conditioner is used to compute new seeds for the rate
matcher. Based on the current state, the rate matcher
computes 128-bit random numbers. Reseeding is done
whenever the conditioner has collected enough random
numbers from the entropy source, or if at most 512 128-
bit random numbers have been generated by the rate
matcher. The conditioner as well as the rate-matcher
are based on AES. Figure 3 gives an overview of the
RNG design.
The rate matcher generates the 128-bit output rof
the RNG and takes the seed (s, t) generated by the
conditioner unit as input. The rate matcher has two in-
ternal state registers: a 128-bit register Kand a 128-bit
register c. During normal operation, the rate matcher
generates 128 random bits rand updates the state reg-
isters in the following way (r, c, K)=Generate(c,K):
1. c=c+ 1, r=AESK(c)
2. c=c+ 1, x=AESK(c)
3. c=c+ 1, y=AESK(c)
4. K=K⊕x
5. c=c⊕y

Fig. 3 Overview of Intel’s RNG design. An Entropy Source
(TRNG) generates truly random numbers whose entropy
is monitored by the Online Health Test (OHT). The ran-
dom numbers are then fed to a digital random bit generator
(DRBG) consisting of a Conditioner and a Rate Matcher. The
Conditioner is used to periodically reseed the Rate Matcher
which provides the output RnRand of the RNG. The correct
functioning of the RNG is checked at each power up using the
Build-In Self Test (BIST). The Trojan is inserted into the 256
bit state of the Rate Matcher.
Whenever the conditioner has a new seed, consisting of
the 128-bit values sand t, available the internal states
cand Kare reseeded using the (c,K)=Reseed(s,t,c,K)
function:
1. c=c+ 1, x=AESK(c)
2. c=c+ 1, y=AESK(c)
3. K=K⊕x⊕s,
4. c=c⊕y⊕t
Under low load, the rate matcher reseeds after each
output of r. Under heavy load, the rate matcher gen-
erates several random numbers rbefore it reseeds, up
to a maximum of 512. However, even under heavy, load
the rate matcher should reseed long before reaching its
maximum of 512 [7].
3.2 Dopant-Trojan for Intel’s DRBG
A 128-bit random number rgenerated by the rate matcher
is the result of an AES encryption with an unknown
128-bit random input cand an unknown, random key
K. The attacker has a chance of 1/2128 to correctly
guess a random number resulting in an attack com-
plexity of 128-bits. The goal of our Trojan is to reduce
the attack complexity to nbits, while being as stealthy
as possible. This is achieved by cleverly applying our
dopant-based Trojan idea described in Section 2 to in-
ternal flip-flops used in the rate matcher. In the first
step we modify the internal flip-flops that store Kin
a way that Kis set to a constant. In the second step
the flip-flops storing care modified in the same way,
but nflip-flops of care not manipulated. Hence, only
(128 −n) flip-flops of care set to a constant value. This
has the effect that a 128-bit random number rdepends
only on nrandom bits and 128 + (128 −n) constant
bits known to the Trojan designer. The owner of the
Trojan can therefore predict a 128-bit random number
rwith a probability of 1/2n. This effectively reduces
the attack complexity from 128-bit down to nbits. On
the other hand, for an evaluator who does not know
the Trojan constants, rlooks random and legitimate
since AES generates outputs with very good random
properties, even if the inputs only differ in a few bits.
Our Trojan can be implemented by only modifying
the flip-flops storing cand K, while all other parts of the
target design remain untouched. Two different Trojan
flip-flops are needed: one which sets the flip-flop out-
put to a constant ‘1’ and one which outputs a constant
‘0’ regardless of the inputs. The DFFR X1 flip-flop of
the used Nangate Open Cell library [15] has two out-
puts, Qand its inverse QN. To implement our Trojan,
the drain contact of the p-MOS transistor that gener-
ates signal Qis shortened to VDD by applying n-dopant
above the drain contact, as explained in Section 2. Si-
multaneously, the source contact of the n-MOS transis-
tor for signal Qis disabled by applying p-dopant to the
source contact. Hence, the output signal Qgenerates
a constant output of VDD regardless of its input. The
inverse output QN is modified in the same way, only
that this time the drain contact of the n-MOS transis-
tor is shortened to GND and the source contact of the
p-MOS transistor is disabled. This leads to a constant
output of ‘0’ for QN. The same modifications are used
to generate a flip-flop Trojan to constantly provide an
output of Q=‘0’ and QN=‘1’ by switching the roles of
the n-MOS and p-MOS transistors. Note that only four
of the 32 transistors of the DFFR X1 flip-flop are mod-
ified as can be seen in Figure 4. But 28 transistors on
the other hand stay untouched and therefore will still
switch according to the input. This results in a smaller
but still similar power consumption for a Trojan flip-
flop compared to a Trojan-free flip-flop.
Fig. 4 Layout of the Trojan DFFR X1 gate. The gate is
only modified in the highlighted area by changing the dopant
mask. The resulting Trojan gate has an output of Q=VDD
and QN =GND.

3.3 Defeating functional testing and statistical tests
It is a standard procedure to test each produced chip
for manufacturing defects. In addition to these tests,
the produced RNGs will also be tested against a range
of statistical tests in order to be NIST SP800-90 and
FIPS 140-2 compliance. Furthermore, to be compliant
with FIPS 140-2, the RNG needs to be tested at each
power-up to ensure that no aging effects have dam-
aged the RNG. For this purpose Intel’s RNG design
includes a Built-In-Self-Test unit that checks the cor-
rect functioning of the RNG in two steps after each
power-up. In the first step, the entropy source is dis-
abled and replaced by a 32-bit LFSR that produces a
known stream of pseudo-random bits. The BIST uses
this pseudo-random bit stream to verify the correct
functioning of the OHT and feeds this bitstream to the
conditioner and rate matcher. A 32-bit CRC checksum
of the 4 x 128-bit output buffer that stores the last
four outputs r1,...,r4of the rate matcher is computed.
This 32-bit CRC checksum is compared against a hard-
coded value to verify the correct functioning of the con-
ditioner and rate matcher. If the checksum matches,
the RNG has passed the first part of the BIST. In the
second part of the BIST the conditioner, rate matcher
and output buffer are reset and the entropy source is
connected again. The OHT tests the entropy of the en-
tropy source and simultaneously seeds the conditioner
and rate matcher. If the OHT signals the BIST that the
entropy of the entropy source is high enough, the BIST
is passed and the RNG can generate random numbers.
In [9] it is stated that “This BIST logic avoids the
need for conventional on-chip test mechanisms (e.g.,
scan and JTAG) that could undermine the security of
the DRNG.” This fact is also mentioned in an Intel pre-
sentation in which it is argued that for security reasons
the RNG circuitry should be free of scan chains and
test ports [24]. Therefore, to prevent physical attacks,
only the BIST should be used to detect manufacturing
defects. From an attacker’s point of view, this means
that a hardware Trojan that passes the BIST will also
pass functional testing. Although Intel’s BIST is very
good at detecting manufacturing and aging defects, it
turns out that it cannot prevent our dopant Trojans.
One simple approach to overcome the BIST would be
to add a dopant Trojan into the BIST itself to con-
stantly disable the error flag. However, it could be very
suspicious if the BIST never reports any manufacturing
defects.
To pass the BIST, the Trojan rate matcher needs
to generate outputs r0
1,...,r0
4during the BIST that have
the same 32-bit CRC checksum as the correct outputs
r1,...,r4. Since the input to the rate matcher during the
BIST is known, the Trojan designer can compute the
expected 32-bit CRC checksum. He then only needs to
find a suitable value for the Trojan constants c[1 : 128]
and K[1 : 128 −n], which generate the correct CRC
checksum for the inputs provided during the BIST. Since
the chance that two outputs have the same 32-bit CRC
is 1/232, the attacker only needs 232/2 tries on average
to find values for cand Kthat result in the expected
32-bit CRC. This can easily be done by simulation. By
cleverly choosing cand Kthe Trojan now passes the
BIST, while the BIST will still detect manufacturing
and aging defects and therefore raises no suspicion.
Since the Trojan RNG has an entropy of nbits and
uses a very good digital post-processing, namely AES,
the Trojan easily passes the NIST random number test
suite if nis chosen sufficiently high by the attacker. We
tested the Trojan for n= 32 with the NIST random
number test suite and it passed for all tests. The higher
the value nthat the attacker chooses, the harder it will
be for an evaluator to detect that the random numbers
have been compromised.
Detecting this Trojan using optical reverse engineer-
ing is extremely difficult since only the dopant masks of
a few transistors have been modified. As discussed, de-
tecting modifications in the dopant mask is extremely
difficult in a large design, especially since only a small
portion of a limited number of gates were modified.
Since optical reverse-engineering is not feasible and our
Trojan passes functional testing, a verifier cannot dis-
tinguish a Trojan design from a Trojan-free design. This
also means that the verifier is not able to reliably verify
a golden chip. But without such a verified golden chip,
most post-manufacturing Trojan detection mechanisms
do not work.
4 Case-study 2: Side-channel Trojan
In the first case study we showed how our dopant Tro-
jan can be used to compromise the security of a real
world system by shorting specific signals to GND and
VDD . With the second case study we want to emphasize
the flexibility of the dopant Trojan. Instead of modify-
ing the logic behavior of a design, the dopant Trojan
is used to establish a hidden side-channel to leak out
secret keys. We prove this concept by inserting a hid-
den side-channel into an AES SBox implemented in a
side-channel resistant logic style.
We chose the side-channel resistant logic style iMDPL
for our target implementation despite the fact that it
has some known weaknesses, namely imbalanced rout-
ing, that can enable some side-channel attacks [14]. Our
target iMDPL SBox is reasonably secure and we would
like to stress that the focus of this work is hardware

Trojans and not side-channel resistant logic styles. Our
point here is that our Trojan modifications do not re-
duce the side-channel resistance against common side-
channel attacks while enabling the Trojan owner to re-
cover the secret key. In the following section a brief
introduction of iMDPL is given and then the dopant
based side-channel Trojan is explained.
4.1 iMDPL
The improved Masked Dual Rail Logic (iMDPL) was
introduced in [16] as an improvement of the Masked
Dual-Rail Logic (MDPL) [17]. There are three main
ideas incorporated in iMDPL:
1. Dual-Rail: for every signal a, both the true and the
complementary signal (indicated with ¯a) are com-
puted. Therefore the same number of 1’s and 0’s
are computed regardless of the input. This prevents
attacks based on the Hamming weight.
2. Precharge phase: Between two clock cycles, there is
always a precharge phase in which all iMDPL gates
(besides registers which have to be treated differ-
ently) are set to 0. This prevents attacks based on
the Hamming distance.
3. Mask bit: Due to imbalances in routing inverse sig-
nals and process variations, the power consumption
of a signal amight differ from that of its inverse
signal ¯awhich can lead to side-channel attacks. In
iMDPL a random mask bit is used to randomly
choose between aand ¯ato mask the power con-
sumption.
In an iMDPL gate, every input and output bit as well
as its inverse is masked with a mask bit m. An iMDPL-
AND gate performing the operation q=a&bhas six
inputs: The masked input values am=a⊕m, ¯am=
a⊕¯m,bm=b⊕m,¯
bm=b⊕¯mand the mask bit m
and its inverse ¯m. The two outputs of an iMDPL-AND
are qm=q⊕mand ¯qm=q⊕¯m.
The schematic of an iMDPL-AND gate is shown
in Figure 5. It consists of a detection stage, an SR-
latch stage and two majority gates with complemen-
tary inputs. If one input of a 3-input majority gate is
set to 0, the majority gate behaves like an AND gate.
If one input is set to 1, the majority gate behaves like
an OR gate. For the mask bit m= 0, the lower Ma-
jority gate with the inputs am,bmand mcomputes
q=qm=a&band the upper majority gate computes
¯q= ¯qm= ¯a|¯
b. For the mask bit m= 1 on the other
hand the lower majority gate computes ¯q=qm= ¯a|¯
b
and the upper majority gate computes q= ¯qm=a&b.
Hence, the current mask bit decides which inputs and
outputs are the correct ones and which the inverse. It is
also possible to create an iMDPL-OR and iMDPL-NOR
gate using the same structure by switching the out-
puts and/or inputs. In iMDPL all combinational logic
is build using these four basic operations (AND, NAND,
OR and NOR). The detection and SR-latch stage was
introduced in iMDPL to prevent the early propagation
effect and glitches by making sure that all inputs are
in a complementary stage before evaluating. A more
detailed description of iMDPL can be found in [16].
Fig. 5 Schematic of an iMDPL-AND gate consisting of two
Majority gates, a detection logic and an SR-latch stage[16].
As in the previous sections, the 45nm Nangate Open
Cell library was used for our implementation of an area
optimized Canright [3] AES SBox in iMDPL. Since the
target library does not have a 3-input majority gate,
we used a six input AND-OR-INVERTER (AOI) gate
configured as a 3-input not-majority gate together with
an inverter to build the majority gate2.
4.2 iMDPL-Trojan
To insert a Trojan into the iMDPL SBox implementa-
tion, we replace two AOI gates from a single iMDPL
gate with Trojan AOI gates that create a predictable,
data-dependent power consumption independent from
the mask bit. Modifying only single gates makes in-
serting the Trojan into the design after place & route
very simple, since we do not need to worry about any
additional routing or find empty space in the design.
Figure 6 shows the schematic of the used AOI gate con-
figured as a 3-input not-majority gate. Two changes are
made to this not-majority gate to create a large data-
dependent power consumption. First, the two topmost
p-MOS transistors are removed by shorting their output
contacts to VDD. Secondly, the strength of the remain-
ing p-MOS transistors is decreased by decreasing their
2We would like to note that the layout of a majority gate
is very similar to an AOI gate and we verified that the Trojan
also works with a standard majority gate.

effective width. These changes are depicted on the right
side of Figure 6.
A
A
AA
B
B
B
B
C
C
CC
Y
VDD
GND
A
A A
B
B
B
CC
Y
VDD
GND
weak transistors
AC
a) Trojan free AOI222 Gate b) Trojan AOI222 Gate
Fig. 6 Schematic of the Trojan-free and Trojan AOI222 X1
gate configured as a 3-input not-majority gate.
The Trojan not-majority gate behaves like the Trojan-
free gate except for the input pattern A= 0, B= 1,
and C= 1. In the unmodified not-majority gate the
pull-up network is inactive and the pull-down network
is active, resulting in an output value of 0. However, in
the Trojan gate the pull-up as well as the pull-down net-
work are both active for this input pattern. Due to the
reduced size of the p-MOS transistors, the pull-up net-
work is much weaker than the pull-down network and
the resulting output voltage is therefore still close to 0.
In a sense we have turned the not-majority gate into a
pseudo-n-MOS gate for this input pattern. Hence, the
output values of both the Trojan-free and Trojan gate
are the same, but there is a large power consumption in
the Trojan gate for this input pattern due to the con-
nection between GND and VDD . For all other inputs
only the pull-up or pull-down network is active for the
Trojan gate as well as the Trojan-free gate.
If the two not-majority gates of the iMDPL gate
are exchanged with this Trojan gate, a high power con-
sumption is generated whenever one of the two AOI
gates has the input A= 0, B= 1, and C= 1. In our
configuration this is the case if am= 0, bm= 1, m= 1
or if ¯am= 0, ¯
bm= 1, ¯m= 1 which turns out to be
the case for a= 1, b= 0 regardless of the value of m.
Hence, the Trojan iMDPL gate has a data-dependent
power consumption that is independent of the mask bit
m.
We used the technique of dopant Trojans described
in Section 2 to realize our Trojan AOI gate. The modi-
fications were done using Cadence Virtuoso Layout ed-
itor and are shown in Figure 7(b). The Trojan gate
passed the DRC check and we used Calibre PEX in
Virtuoso to do the netlist and parasitic extraction. The
Trojan and Trojan-free gate were simulated in HSpice.
The propagation delay, rise and fall time of a Trojan
iMDPL gate are very similar to the Trojan-free iMDPL
implementation. This makes it possible to place our
Trojan gates even in the critical path without creating
timing violations. The additional power consumption
when the Trojan activates depends on the used clock
frequency, since the majority of power consumption of
the Trojan is static current due to the connection be-
tween VDD and GND. Even at a very high frequency
such as 10 GHZ, the Trojan gate consume roughly twice
as much power when the Trojan activates compared to
the Trojan-free counterpart.
To insert our Trojan iMDPL gate in the layout of
the target SBox implementation after place & route we
need to identify an iMDPL gate that serves as a suit-
able Trojan location and replace the AOI gates of this
target iMDPL gate with the Trojan AOI gate. Finding
a suitable location does not require a detailed knowl-
edge of the target SBox. In fact, the right location can
be identified using simulation. The individual iMDPL
gates can easily be identified by searching for AOI gates
connected with inverse inputs. In the first step, we sim-
ulated the SBox for all 512 possible inputs (for each
mask there are 256 different inputs) and stored the in-
puts and outputs for the tested AOI gates. Then, a
matlab script was used to test the performance of pos-
sible Trojan target locations. We chose a target location
that (1) had a small correlation with the Trojan power
model for all false key guesses to make it easy for the
owner of the Trojan to use it and (2) a location which
did not increase the vulnerability against the considered
side-channel attacks. We tested (2) by performing the
considered side-channel attacks on hypothetical power
traces based on the Trojan power model. Once we lo-
cated a good Trojan location we simply replaced the
corresponding AOI gates with the Trojan AOI gate.
4.3 Trojan effectiveness evaluation
To verify the correct functioning of the Trojan iMDPL
gate and to show that the Trojan gates do not violate
timing requirements even if the Trojan gate is placed in
the critical path, transistor-level simulations were per-
formed. These simulations of a Trojan and a Trojan-
free iMDPL gate were performed using HSpice and the
parasitic extraction was done by Calibre PEX. Table
1 shows the delay, rise and fall times of the Trojan-
free and the Trojan iMDPL gate for a load capacitance
of 5.4fF, the equivalent of the gate capacitance of two
iMDPL gates. The Trojan-free and the Trojan gate have
very similar timing characteristics. In most cases the
Trojan gate is even faster than the Trojan-free gate.
Therefore, it is possible to exchange an iMDPL gate
with a Trojan iMDPL gate even if it is in a time-critical
path.

(a) Trojan-free AOI gate (b) Trojan AOI gate
Fig. 7 On the left (a) the layout of the unmodified AOI222 X1 gate and on the right (b) the Trojan AOI222 X1 gate is shown.
In the Trojan gate the p-MOS transistors in the upper left active area have been shorted with the n-well by replacing the
p-implant with n-implant. The strength of the remaining p-MOS transistors in the upper right active area have been reduced
by decreasing the p-implant in this area.
Trojan-free Trojan gate
A B M 0→1 1→0 Risetime 0→1 1→0 Risetime
0 0 0 121.7 ps 83.51 ps 20.70 ps 115.6 ps 85.78 ps 20.23 ps
0 0 1 119.0 ps 78.45 ps 19.67 ps 111.7 ps 79.88 ps 19.44 ps
0 1 0 147.0 ps 84.00 ps 31.60 ps 134.2 ps 85.65 ps 26.75 ps
0 1 1 149.0 ps 81.82 ps 26.49 ps 136.1 ps 82.78 ps 27.78 ps
1 0 0 153.2 ps 85.49 ps 31.60 ps 142.1 ps 74.69 ps 32.74 ps
1 0 1 152.0 ps 82.47 ps 28.45 ps 139.3 ps 70.72 ps 31.15 ps
1 1 0 135.0 ps 78.15 ps 25.80 ps 125.7 ps 81.12 ps 25.37 ps
1 1 1 138.1 ps 80.66 ps 27.57 ps 128.6 ps 84.54 ps 26.83 ps
Table 1 Performance of the Trojan-free and Trojan iMDPL-AND gate for different input patterns and a load capacitance of
5.4fF. Aand Bdepict the unmasked inputs to the iMDPL-AND gate and Mthe mask bit. The column “ 0 →1” shows the
propagation delay of the evaluation phase and “1 →0” the propagation delay of the precharge phase in picoseconds. “Risetime”
represents the risetime of either Ymor ¯
Ymduring the evaluation phase.
For the simulation of the entire SBox after place
& route Synopsys Nanosim was used. Nanosim is not
as precise as HSpice but the used simulation configu-
ration3is still very precise and does take internal and
routing capacitances into account. The needed inter-
connect parasitics were extracted using Cadence En-
counter and Calibre PEX was used again to extract
the transistor level parasitics of the Trojan and Trojan
free AOI gate. The transistor level parasitics for the
other gates were taken from the NangateOpenCell li-
brary. The side-channel analysis was performed using
Matlab scripts.
To verify the correct functioning of our Trojan we
performed a side-channel attack with the Trojan power
model using the Trojan Sbox implementation and the
Trojan-free implementation on simulated power traces.
Figure 8(a) shows the result of the attack on the Trojan
3Simulations were performed with Synopsis Nanosim us-
ing the following configuration: sim=4, model=4, net=4, set
powernet default mode=5, set sim ires 1pA, set print ires 1pA
and set sim leak ires=1fA.
SBox and Figure 8(b) shows the result of performing the
same attack on the Trojan-free implementation. The
correct key can clearly be distinguished for the Trojan
SBox with a correlation close to 1. It is also interest-
ing to note that the Trojan generates leakage current
compared to switching current. Hence, one can make
power measurements after most switching activity has
occurred and use integration to increase the signal-to-
noise ratio. This makes using the Trojan easy in a prac-
tical setting. As expected, the Trojan power model does
not reveal the key in the Trojan-free implementation,
which shows that the side-channel was indeed produced
by the added Trojan.
We then compared the side-channel resistance of the
Trojan implementation with the Trojan-free implemen-
tation. Covering all possible side-channel attacks out
of the scope of this paper. We therefore only consid-
ered some of the most common side-channel attacks,
namely 1- and 8-bit CPA [2] and MIA [5]. We found a
small vulnerability in the Trojan-free design, which is in
line with the results from [14]. However, the Trojan did

(a) Trojan design (b) Trojan-free design
Fig. 8 1-Bit CPA on (a) the Trojan design and (b) the Trojan-free design using the Trojan power model with the evaluation
phase starting at 0ns and the precharge phase starting at 15ns. The correct key is shown in black and the false keys are shown
in gray. The correlation for the correct key in the Trojan design goes up to 0.9971.
not increase this weakness and the Trojan design is as
side-channel resistant as the Trojan-free design against
the considered side-channel attacks. In the following a
detailed analysis of the side-channel resistance of the
Trojan and Trojan-free design is provided.
4.4 Side-channel analysis of the Trojan and
Trojan-free design
The target iMDPL SBox implementation suffers to a
certain degree from the general problem of iMDPL,
pointed out by Moradi et.al. [14], namely that the dif-
ferent masks have different routing and timing charac-
teristics and therefore a different power profile. Dur-
ing the precharge phase a Correlation-Power Analysis
(CPA) [2] using an 8-bit hamming weight (HW) model
is feasible as can be seen in Figure 9(a). However, the
simulations are noise free, meaning there is no algo-
rithmic noise from other SBoxes and other parts of the
AES algorithm such as MixedColumns. Furthermore,
no measurement noise nor thermal noise is present as
well as no filtering effects due to sense resistors and
capacitances of the global power supply as in a real
measurement. In a real-world scenario the measured
correlation would therefore be much smaller and the
attack not trivial. For all other time instances outside
the shown 14.8ns to 16ns window the 8-bit CPA was
unsuccessful.
But the insertion of the Trojan does not have any
impact on the attack as can be seen in Figure 9(b). The
correlation during the point of attack does not increase
but stays the same. For all other time instances the
correct key cannot be recovered using the 8-Bit CPA
and therefore the Trojan does not decrease the security
against this attack.
1-bit CPA attacks on the output of the Trojan de-
sign were unsuccessful for all 8 bits. As an example, Fig-
ure 10(b) shows the result of the 1-bit CPA attack using
the least significant SBox bit. For no point in time does
the correct key reach a maximum. Interestingly, Mutual
Information Analysis (MIA) [5] was unsuccessful even
at the time instance where the CPA was successful for
both the Trojan as well as the Trojan-free design. A
1024 bin histogram method with an 8-bit HW distin-
guisher was used for the first MIA on the Trojan design.
The result of this attack can be seen in Figure 9(b).
The correct key cannot be distinguished from false keys
since the correct key never reaches a maximum mutual
information value. We assume that — likely by hap-
penstance of the routing algorithm — the leakage dur-
ing precharge must behave very close to the hamming
weight power model and therefore the CPA is more suc-
cessful than MIA. Before using an area-optimized Can-
right AES SBox we tested our iMDPL design flow using
a table look-up based AES SBox which resulted in a
much larger design. For this design, MIA actually per-
formed better than CPA in the 8-bit HW model which
suggests that it depends on the design and routing al-
gorithm if MIA attacks have better results than CPA
attacks. We also tried to increase the bin size to 20000
but the MIA remained unsuccessful.
Further, MIA attacks with a distinguisher based on
4 or 6 bits of the SBox output were performed. These
attacks were unsuccessful for both the Trojan as well
as Trojan-free design. It is important to note that the
Trojan was placed in a well chosen location so that the
Trojan power model does not have a direct relation to
the SBox output. This explains why the Trojan was
not detected by MIA attacks since the output of the
SBox is used as an input to the distinguisher function.

(a) Trojan-free design (b) Trojan design
Fig. 9 8-Bit HW CPA attack on (a) the Trojan-free design and (b) the Trojan design with the precharge phase starting at
15ns. The correct key, highlighted in black, can be distinguished. However, the correlation coefficient of the attack for both
the Trojan and Trojan-free is the same.
(a) MIA attack (b) 1-Bit CPA
Fig. 10 Figure (1) shows the result of a MIA attack with a 1024 bin histogram method and an 8-bit HW distinguisher for the
Trojan design. The correct key, highlighted in black, never reaches the maximum for any time period and therefore the attack
is unsuccessful. On the right the results of a 1-bit CPA on the first bit of the SBox output of the Trojan design is shown. Again
the correct key, highlighted in black, can not be distinguished from false keys at any time instance.
The well chosen position of the Trojan is also the main
reason why the 1- and 8-bit CPA attack did not reveal
the Trojan. We specifically chose the Trojan to not be
triggered by these power models.
Since the Trojan did not reduce the resistance to
8-Bit HW CPA attacks compared to the Trojan-free
implementations and all other attacks were unsuccess-
ful on the Trojan design, the introduced Trojan does
not reduce the side-channel resistance against the con-
sidered side-channel attacks. Therefore, to an evaluator
testing these side-channel attacks, the Trojan design ap-
pears to be side-channel resistant. The owner of the Tro-
jan on the other hand can use the secret Trojan power
model to successfully attack the design. But we would
like to note that this does not mean that the Trojan
is undetectable using other side-channel attacks. How-
ever, the analysis shows that if the attacker knows the
methods the design will be tested again (e.g. because
it is listed in a standard) he can specifically design the
Trojan so that these attacks are unsuccessful.
The side-channel analysis showed that we have suc-
cessfully established a hidden side-channel that can leak
out secret keys very reliably while not decreasing the
side-channel resistance against the most common side-
channel attacks. Hence, the newly introduced Trojan
side-channel can only be used by the owner of the Tro-
jan who knows the secret Trojan power model. Since
we did not change the logic behavior of any gate, func-
tional testing cannot detect the Trojan. As discussed in
Section 2, detecting this Trojan using optical inspection
is very challenging since we only modified the dopant
masks. Without being able to detect the Trojan using
functional testing or optical inspection, an attacker can-
not distinguish a Trojan chip from a Trojan-free chip.

Hence, an evaluator cannot verify a golden chip and
therefore methods that rely on a golden chip have only
limited use in detecting the Trojan. This shows that
detecting a dopant-based side-channel Trojan would be
challenging in practice using known methods.
5 Conclusions
In this paper we introduced a new type of sub-transistor
level hardware Trojan that only requires modification
of the dopant masks. No additional transistors or gates
are added and no other layout mask needs to be modi-
fied. Since only changes to the metal, polysilicion or ac-
tive area can be reliably detected with current optical
inspection techniques, our dopant Trojans are immune
to optical inspection, one of the most important Tro-
jan detection mechanism. Also, without the ability to
use optical inspection to distinguish Trojan-free from
Trojan designs, it is very difficult to find a chip that
can serve as a golden chip, which is needed by most
post-manufacturing Trojan detection mechanisms.
To demonstrate the feasibility of these Trojans in a
real world scenario and to show that they can also de-
feat functional testing, we presented two case studies.
The first case study targeted a design based on Intel’s
secure RNG design. The Trojan enabled the owner of
the Trojan to break any key generated by this RNG.
Nevertheless, the Trojan passes the functional testing
procedure recommended by Intel [9,24] for its RNG de-
sign as well as the NIST random number test suite.
This shows that the dopant Trojan can be used to com-
promise the security of a meaningful real-world target
while avoiding detection by functional testing as well
as Trojan detection mechanisms. To demonstrate the
versatility of dopant Trojans, we also showed how they
can be used to establish a hidden side-channel in an
otherwise side-channel resistant design. The introduced
Trojan does not change the logic value of any gate, but
instead changes only the power profile of two gates. An
evaluator who is not aware of the Trojan cannot attack
the Trojan design using common side-channel attacks.
The owner of the Trojan however can use his knowl-
edge of the Trojan power model to establish a hidden
side-channel that reliably leaks out secret keys.
Detecting this new type of Trojans is a great chal-
lenge. They set a new lower bar on how much overhead
can be expected from a hardware Trojan in practice
(i.e. zero!). Future work should include developing new
methods to detect these sub-transistor level hardware
Trojans.
References
1. D. Agrawal, S. Baktir, D. Karakoyunlu, P. Rohatgi, and
B. Sunar. Trojan Detection using IC Fingerprinting. In
IEEE Symposium on Security and Privacy (SP 2007), pages
296–310, 2007.
2. E. Brier, C. Clavier, and F. Olivier. Correlation Power
Analysis with a Leakage Model. In Cryptographic Hard-
ware and Embedded Systems - CHES 2004, LNCS, pages
16–29. Springer, 2004.
3. D. Canright. A very compact S-box for AES. In Cryp-
tographic Hardware and Embedded Systems - CHES 2005,
LNCS, pages 441–455. Springer, 2005.
4. Defense Science Board. Report of the Defense Science
Board Task Force on High Performance Microchip Sup-
ply. US DoD, February 2005.
5. B. Gierlichs, L. Batina, P. Tuyls, and B. Preneel. Mu-
tual Information Analysis. In Cryptographic Hardware and
Embedded Systems - CHES 2008, LNCS, pages 426–442.
Springer, 2008.
6. C. Gorman. Counterfeit chips on the rise. IEEE Spectrum,
49(6):16–17, june 2012.
7. M. Hamburg, P. Kocher, and M. E. Marson. Analysis
of Intel’s Ivy Bridge Digital Random Number Generator.
Technical Report, Cryptography Research INC., March
2012.
8. M. Hicks, M. Finnicum, S. T. King, M. M. Martin, and
J. M. Smith. Overcoming an untrusted computing base:
Detecting and removing malicious hardware automati-
cally. In IEEE Symposium on Security and Privacy (SP
2010), pages 159–172, 2010.
9. Intel. Intel Digital Random Number Generator (DRNG)
Software Implementation Guide. http://software.
intel.com/sites/default/files/m/d/4/1/d/8/441 Intel
R DRNG Software Implementation Guide final Aug7.pdf,
Aug 2012. Revision 1.1.
10. S. T. King, J. Tucek, A. Cozzie, C. Grier, W. Jiang,
and Y. Zhou. Designing and implementing malicious
hardware. In Proceedings of the 1st USENIX Workshop
on Large-scale Exploits and Emergent Threats (LEET 08),
pages 1–8, 2008.
11. J. Li and J. Lach. At-speed delay characterization for
IC authentication and Trojan horse detection. In IEEE
International Workshop on Hardware-Oriented Security and
Trust (HOST 2008), pages 8–14, 2008.
12. L. Lin, M. Kasper, T. G¨uneysu, C. Paar, and
W. Burleson. Trojan Side-Channels: Lightweight Hard-
ware Trojans through Side-Channel Engineering. In
Cryptographic Hardware and Embedded Systems - CHES
2009, LNCS, pages 382–395. Springer, 2009.
13. S. Markoff. Cyberwar — Old Trick Threatens the Newest
Weapons. New York Times, October 2009.
14. A. Moradi, M. Kirschbaum, T. Eisenbarth, and C. Paar.
Masked Dual-Rail Precharge Logic Encounters State-of-
the-Art Power Analysis Methods. IEEE Transactions on
Very Large Scale Integration (VLSI) Systems, PP(99):1–13,
2011.
15. Nangate Inc. Nangate Open Cell Library, version
PDKv1 3 v2010 12. http://www.si2.org/openeda.si2.
org/projects/nangatelib, August 2011.
16. T. Popp, M. Kirschbaum, T. Zefferer, and S. Mangard.
Evaluation of the Masked Logic Style MDPL on a Proto-
type Chip. In Cryptographic Hardware and Embedded Sys-
tems - CHES 2007, LNCS, pages 81–94. Springer, 2007.
17. T. Popp and S. Mangard. Masked Dual-Rail Pre-charge
Logic: DPA-Resistance Without Routing Constraints. In

Cryptographic Hardware and Embedded Systems - CHES
2005, LNCS, pages 172–186. Springer, 2005.
18. J. Rajendran, V. Jyothi, and R. Karri. Blue team red
team approach to hardware trust assessment. In IEEE
29th International Conference on Computer Design (ICCD
2011), pages 285–288, oct. 2011.
19. J. Rajendran, V. Jyothi, O. Sinanoglu, and R. Karri. De-
sign and analysis of ring oscillator based Design-for-Trust
technique. In 29th IEEE VLSI Test Symposium (VTS
2011), pages 105–110, 2011.
20. D. Sanger, D. Barboza, and N. Perlroth. Chinese Army
Unit Is Seen as Tied to Hacking Against U.S. New York
Times, February 2013.
21. Y. Shiyanovskii, F. Wolff, A. Rajendran, C. Papachris-
tou, D. Weyer, and W. Clay. Process reliability based
trojans through NBTI and HCI effects. In NASA/ESA
Conference on Adaptive Hardware and Systems (AHS 2010),
pages 215–222, 2010.
22. SypherMedia International. Circuit Camouflage Technol-
ogy - SMI IP Protection and Anti-Tamper Technologies.
White Paper Version 1.9.8j, March 2012.
23. A. Waksman and S. Sethumadhavan. Silencing hardware
backdoors. In IEEE Symposium on Security and Privacy
(SP 2011), pages 49–63, 2011.
24. J. Walker. Conceptual Foundations of the Ivy
Bridge Random Number Generator. Presen-
tation at ISTS Computer Science Department
Colloquium at Dartmouth College, Nov 2012.
http://www.ists.dartmouth.edu/docs/walker ivy-
bridge.pdf.
25. J. Yier and Y. Makris. Hardware Trojan detection using
path delay fingerprint. In IEEE International Workshop on
Hardware-Oriented Security and Trust (HOST 2008), pages
51–57, 2008.