In this course, we will study security and trust from the hardware perspective. Upon completing the course, students will understand the vulnerabilities in current digital system design flow and the physical attacks to these systems. They will learn that security starts from hardware design and be familiar with the tools and skills to build secure and trusted hardware.
Hardware Trojan Detection Overview
Loading...
From the course by University of Maryland, College Park
Hardware Security
227 оценки
From the lesson
Hardware Trojan Detection and Trusted IC Design
This week we study hardware Trojan and trusted integrated circuit (IC) design. Hardware Trojans are additions or modifications of the circuit with malicious purposes. It has become one of the most dangerous and challenging threats for trusted ID design. We will give hardware Trojan taxonomies based on different criteria, explain how hardware Trojan work, and then talk about some of the existing approaches to detect them. We define trusted IC as circuit that does exactly what it is asked for, no less and no malicious more. We will illustrate this concept through the design space analysis and we will discuss several practical hardware Trojan prevention methods that can facilitate trust IC design.
Meet the Instructors
Gang QuAssociate Professor
Electrical and Computer Engineering
We have learned hardware Trojan taxonomies, and before we discuss how to
detect hardware Trojans or admit we cannot detect them, let's first take a high level
overview, of hardware Trojan detection and its relationship with trusted IC design.
For a given fabricated integrated circuit, and its specification, the goal of
hardware Trojan detection, is to determine whether the IC has any hardware Trojan, or
whether the IC can be trusted or not.
A hardware Trojan detection algorithm or
mechanism, can report user hardware Trojan found, were not found.
In the case when hardware Trojan is found, we can see that integrate circuit,
is untrusted, but we cannot say that the design team is untrusted.
This is because the design team, may use untrusted design tools or third party IPs.
On the other hand, if the hardware Trojan detects an algorithm did not detect any
Trojan, we can not conclude that the IC is trusted or the design team is trusted.
We can only say that,
this hardware Trojan detection algorithm did not find any Trojan.
And this implies that, it is very hard or
impossible to claim that a IC is 100% trusted.
Even if we try old input combination we can
only say that the system does not have any functional hardware Trojan.
They may still have parametric hardware Trojans in the system, that can
reduce the reliability of the circuits or leak information through set channels.
So in that sense, hardware trojan detection,
is a process to evaluate or to access system's trustworthiness.
Recall that, we have defined or redefined trust,
trusted integrated circuits as an int, integrated circuit that does exactly,
it is asked to do, no less and no malicious more.
So for a system specification, there are many, many different designs, so
we take a approach, consider the design solution space.
So this is a design space and this vertical bar,
partition to be that space into two parts.
The left side is the successful design that meets all the design requirements.
The right pa, pa,
path is the design failures which fail to meet some of the design specifications.
And as we have learned older designs will do something more.
So depends on whether these more things are malicious or
not, we can further petition this ad space into two parts.
The lower right corner here are the malicious functionalities imparted
into the design, and the rest of the part they don't have any malicious or
functionalities which in some sense we call the innocent more.
And finally, assume that we have a hardware trojan detection algorithm or
trust assessment tool.
The tool will e,
will assess the design as every port whether design is trusted or untrusted.
So the latter half, this pa, part is called trusted design and the upper
right corner and the lower left cor, or right corner, is at untrusted design.
So with this three curves, the vertical bar, this red arc, and green
half su, circle here, we partition the design space into eight different regions.
The first region, the successful designs, because they on the left.
They do have malicious functionalities.
But the, the, the two has successfully detected as untrusted.
Region number two is the same as region number one.
However, the two fails to detect the malicious functionalities.
They sync, this design is trusted.
Region number III, is a successful design with no malicious functionalities,
and the two consider this as trusted.
Region number IV, successful design, no malicious functionalities, but
the two accidentally or incorrectly identified this as untrusted.
On the right side of this vertical bar is the whole failure designs.
And the first two the five and
the six they have malicious functionalities and then the two easily
considers them untrusted or trusted, and the trusted case this is an error.
For Region VII these are these are failures with no
malicious functionalities and then the two consider these are trusted.
Region number VIII these are succ, they are failure designs, with no malicious
functionalities and the two successfully identified these as untrusted.
And finally as we have discussed of, from the first week, so in your older details
designs, there might be some backdoors, what we call the security vulnerabilities.
So after this we consider systems vulnerabilities.
And this region inside the circle here, we called region number nine,
these are what we call vulnerable designs with security vulnerabilities.
So in that sense, what we are doing here is to have a good design,
what we want to do is, we want to search in the trusted region,
which is region III and region IV and outside region nine.
We want to find in this regions the best quality design here.
And the hardware, the goal of hardware trojan detection,
they have a different goal here.
Remember, this is the hardware trojan detection which trust assessment into
their report.
The report, this part is trusted and the other part, they are untrusted.
And then we do see some false statement here we have
a false positive here with the number IV, this region is trusted but
to report this as untrusted we want to minimize this false positive.
And also the two has three false negatives.
Region number II, Region number VI and region number VII.
And we need to pay special atten, attention to
region number II because these all have some malicious functionality but
that the tool fails to detect it.
For VI and VII it is of least importance because they are failure, design failures.
So before we talk about how to detect hardware trojans, let's step back and
then think about physical attacks to a system.
Assume this is my chip.
It has my intellectual property, it has my secret data.
And, the attackers want to launch what we have discussed the physical attacks to
the, to the chip.
Trying to either reveal my design details or
trying to steal the secret data stored in the system.
And we have learned the different physical attacks, starting from
the invasive attack, semi-invasive attack, or non-invasive, invasive attacks.
And the two of the most, I mean, powerful attacks, they are reverse engineering and
search channel analysis attacks.
So these attacks they'll be able to to they'll be, I mean, be able peel of
the chip layer by layer trying to figure out what is in the structure of the chip,
and then trying to find out the functionality of my design.
Or it can go through set channel, trying to analyse and then steal the data.
So now let's consider, I don't have this chip here but I want to design a chip, and
then someone design a chip for me.
I got this design back, and
I have this question, whether the chip has any hardware trojan or not.
So what I want to do here is, I want to do a hardware trojan detection.
And my goal is to detect hardware trojan,
or trying to find any information related to hardware trojan.
So take a look of these two scenarios.
They are very, very similar, or in some sense they are identical.
In both cases, you have a chip which you, you don't know all the details.
And your goal is trying to find out the details of the chip.
What it does and what kind of information that chip has.
If that is the case, what I can do for
hardware trojan detection, I can use exactly this attacker's used for
physical attacks to the system to do hardware trojan detection.
If that is the case I can claim that hardware program detection is easy,
but is it really easy?
So let's take a look at this approach which is based on reverse engineering.
So this is what we call the de,
the destructive hardware Trojan detection, or it is similar to invasive attacks.
So what, what it does is it's going to pick one or
a couple thumb holes inte, integrate circuits.
And, it, it's going to remove the package to expose the die of each of the ICs.
And then, it's going to conduct a reverse engineering trying to
reveal the inner structure of the system and
trying to figure out the functionality of the system.
Whenever we find any malicious addition or modification to the system or
to the wires or to any physical features, to the,
to the design we can claim hardware trojan found.
Technically this is correct and you should be able to capture all of
the hardware trojans, regardless they're functional trojans or parametric trojans.
However, these are not practical for a couple of reasons.
So first, this process is very very expensive.
Not only do you need the expensive equipment and
tools, they also require detailed design knowledge and also,
there are many, many cases, they are very, very time consuming.
And second, even if we find any additional things in the design,
and how do we know they are, these more things they are malicious, and
how do we know they are intentionally added, or accidentally added.
And then finally, remember we start by picking one sample or a couple of samples.
And it is possible for
the foundry to embed hardware trojans only on several chips not all the chips.
So if we pick the sample that doesn't have hardware trojan, we cannot claim that
all the chips fabricated by this foundry they don't have hardware trojans.
So there are several factors that make hardware trojan detection,
detection a very challenge task.
First the hardware trojans, as we have seen from the hardware trojan taxonomies,
they are very, very versatile.
They have different sizes from largeblocksof powerful antennas to
some very small kill, kill switch, a couple of gates.
Or even you don't have any caves, you just make the, the wires thinner or
change the physical features of some other components.
And hard, hardware trojan can be hidden in many,
many different locations of the system.
Can be in the memory, can be in the IO device, can be in the processor.
So, and then most of the hardware trojans, they're not active.
They stay very very quiet, they sleep there un, until it has been,
it will be activated.
And they will take different forms or different types, as we
had mentioned about functional hardware trojans or parametric hardware trojans.
This makes the detection of hardware trojans very very challenged.
And second, the test, the traditional testing tools or
verification tools, fail to do the hardware trojan detection.
Because they're developed to detect manufacturer defects or
faults, not for this intentionally added malicious purpose.
And finally, it is very difficult to distinguish between hardware trojan and
other noises.
By noise we mean a few different scenarios.
So first, the hardware trojan detection algorithms or
the testing tools, they may have errors, fail to find the hardware trojan.
And also the side channel, they may have noise and
then the measurement we got from the side channel, we have errors.
This will make hardware trojan detection algorithm based on side channel trying to
create some errors.
And also we have talk about earlier.
They have functional noise.
For example, the don't care conditions.
It can be accidentally implemented to carry some malicious purpose.
And finally, there might be manufacture variations.
For example, some wires become thinner,
some special voltage becomes higher or lower.
I know this will make hardware trojan detection algorithm or
approach much difficult.
So, besides the destructive approach we have seen earlier, there are also a lot of
non-destructive, destructive approaches, that mainly falls into two categories.
The run-time monitoring approach and the test-time detection approach.
For the test time detection approach, they have logical detect and
side channel analysis approach.
And we're, we're going to analyze this later in the next lecture.
And to end today's lecture,
we are going to study how the hardware trojan will be added or
what's the hardware trojan designers, they will think [SOUND].
So as a hardware Trojan in embedder or designer.
So the first, we have to have some motivations to insert hardware Trojans,
and for their motivation normally starts by trying to see what other system or
applications they are targeting.
This can be a financial institute or
maybe a banking system or this can be military systems.
And they have to consider what is the pay load when hardware trojan is
activated versus the design cost to embed such hardware torque.
And then they have to consider technically, when, where, and
how to embed the hardware trojans?
There goal is, is two folded.
First they want the hardware trojan to be effective, in a sense that they want,
want to be able to trigger hardware trojan at the right time at the right place.
And they want to make the damage as large as possible.
And second, they want to make this hardware trojan stealthy,
in the sense that it will be hidden well and
then the hardware trojan detection algorithm cannot find them.
Take the kill switch, for example.
In this case, the hard, the, the trojan designers,
they want to control the, the hardware, this hardware kill, kill switch.
They want to make sure that this switch will be switched at the right time and
the right, right place to disable the components they want to control.
And second, they want to have little, very little, or no change to the design.
Both to the functionality of the system, and the layout.
This, the goal is trying to av, avoid being detected by either the test of
time or doing the side channel attacks, the side channel analysis approach.
And finally, because the kill switch, so
the attacker wants to have some control of the trigger.
So the trigger, do you want to have good control ability?
It normally has to be based on rare event, and
they want to have an internal control switch.
So with the understanding of what's the attacker will
think about having a better hardware trojan, in this case the kill switch.
We can design our hardware trojan detection mechanisms to
detect kill switch.
For example, we'll first identify the potential target hardware components or
blocks that the attackers may be interested.
And second, for this block, for each of this block's B,
we can do a test-time formal verification of B's control signals and
input signals, make sure they are all secure.
And at the run-time we can do the monitoring of the controls signals to
the block B and also the input-output relations,
make sure that the correct outputs will come with the input.
And in the meanwhile we can try to monitor the stat channels to see if
there is any abnormal behaviors.
And finally we can do a very strict control of
outside particular wireless signals.
And all the blocks that are connected to this block B.
This is because we know this is a kill switch.
So ta for the kill switch to work, it must have some trigger.
So with all this precautions, we cannot say that we have
100% guarantee to protect the system from this attack of kill switch.
However, once we have all these mechanism in place for
the attacker to impact a kill switch into the system, it becomes much harder.
Ознакомьтесь с нашим каталогом
Присоединяйтесь бесплатно и получайте персонализированные рекомендации, обновления и предложения.
Coursera делает лучшее в мире образование доступным каждому, предлагая онлайн-курсы от ведущих университетов и организаций.
© Coursera Inc., 2018 Все права защищены.
