0:49

And the third reason here is so when people design hardwares to implement

applications, implement functions, when you implement for example crypto crimi,

primitives, what they consider is performance, not security.

So this potentially can introduce security vulnerabilities into the system.

Finally, there might be malicious designers, malicious foundries.

They may add hardware trojans into the hardware.

1:31

So today we are going to talk about microchip supply chain security and

the back doors.

And all the other concerns we are going to talk about later.

So let's start with the microchip supply chain.

So this figure is coming from a 2006 report

from the Defense Advanced Research Projects Agency.

It shows the design goes from a user specification.

Goes to the design team for design.

Goes to the manufacturer for fabrication.

And then eventually deliver back to the system, back to the system user for

testing and for deployment and monitoring.

So when the entire design and fabrication phase is in, in house,

it can be under control, everything is trusted.

However, with the increased design complexity, and

with the off shore foundry, a lot of these plugs becomes untrusted.

2:25

So for example, this design team, it may be trusted, we might say okay,

okay, you have this design team for

years, but however, they are using models, which come from other sources.

They are using third party intellectual properties.

They are using design tools.

And these things may not be designed with a trusted source.

And also when we talk about the foundries, these are oversee of, for foundries.

They're out of our control.

So what we have here is only the phase when we

specify the system we can trust it.

When we get the system back we can do the test by ourself.

We'll trust our testing.

When we deploy the system.

When we monitor the system we can trust this.

And everything the middle we may not trust it.

3:12

So now let's come down to see a couple more concrete examples.

So the first example we have is coming from the reveal slides for

digital logical design.

So where, where do we have this 3-input encoder.

So there are three bits input x, y and z.

And at, at any time, each, any one of them can be one, the only one.

And what we want to do is we want to encode this with a two bit code,

which will be fit into the next module as input.

3:41

So if you remember from the review slides,

what we have here is the optimal design looks like this.

A is the complement of z, and then b, b is the complement of y.

So we know this is the best design.

However, there might a couple of security problems for this design.

3:59

So first if we have 000 as the input,

following this design, a will be 1, which is the complement of z.

And then b will also be 1, which is the complement of y.

So this overall will give us an output 11 as the code.

Which coincides with the code for inputs combination 100.

So this potentially becomes a backdoor to the case of input 100.

And the second question, well, maybe actually is a more severe problem.

So when we have inputs such as 011 or 111,

the output of this optimal design, give us 00 as the output.

Which will be feed into the next module as input, but

however if you come back to our system specification here,

5:10

So the next slide we're going to see an example of sequential system design.

Where we have a three state find-a-state machine.

And we have state 00, state 01, and 10.

And this table shows, this diagram shows you that if I'm at state 00 for

example I'll input X equal to zero, I'm going to move to state 01 and output a 1.

So if you follow the traditional design we have reviewed in the review slides.

What we have here is we need to flip flop the A and the B,

we encoded the two bits 0 and 0 or 01110.

And then we need the input, and

then we need to specify what will be the next stage.

'Kay?

So, for example, like the one we have mention earlier, start from stage 00.

I input x equal to 0, I'm going to move to state 0, 1 okay.

6:29

So for example here, 01, that is my current state.

Then if input is 0, I don't care where it goes.

I don't care what is the next state.

But however, from this system here, you cannot generate I don't care.

When the system is at state 01,iIf you give 0 as

an input the system has to direct you to a deterministic state.

7:11

What happens if those has counted one?

So this give you another state,

state 11, which is not specified in the original system specification here.

And however when the system is designed in this way,

you must have some next state when the current state is 11.

7:43

So this leads us to the following five finite state machine model for

the system, actually, was delivered to us.

This system here.

It is a four stage state machine,

with everything completely specified, particularly these four red edges.

8:02

And now you say okay so, this three-state machine is what I want.

I want you to design a system for, for

me to do this functionality, and this is what is delivered to me, and

if I check all these original constraint, they are met.

8:40

So for example, now we see this finite state machine, it is what we required and

this is what delivered.

And we mentioned that we may have these backdoors here,

and then how can we figure out these backdoors?

Well how can attackers find these backdoors?

So we consider this simple case,

where we assume that state 00 is a state that we want to restrict the access.

So the original system nobody can come back to 00,

there's no incoming edge coming into 00.

But however in this new state, where this new state machine have been implemented,

I do see this address coming back.

I do see this one coming back.

I do see this one coming back.

And then from first state 00 I can go to 01 and then come back.

So the state machine that I have, that designed, everybody can come back and

access state 00.

So this is the potential vulnerability.

But how easy it is for the attackers to find this back door?

[SOUND] To show this, we designed a very simple random walk attack.

So in this attack, the attacker is going to start from a random state, for

example, 01.

And then he is going to try, try a random input for example one again.

And with this one, the system will move him into state 10.

And then we say okay, so this is not what I want, not state 00.

So he is going to try another random input, for example 00.

And then this one stays at state 10, still not the target at 00.

And next time the attacker is going to try input one, and

this will take him directly to the state of 00.

Which means that the attacker now have access to the state 00 which he

doesn't have access.

Where, we, he should not have access.

[SOUND] So now we use the same example to show how

malicious designers can introduce hardware Trojan into the system.

So for example in this case, again we want to limit the access to state 00.

And then malicious designers may say, so I want to have a back door access to it.

And how do I do, do that?