Vulnerabilities and Countermeasures in FPGA Systems

Loading...

En provenance du cours de University of Maryland, College Park

Hardware Security

285 notes

Explore Related Videos

At Coursera, you will find the best lectures in the world. Here are some of our personalized recommendations for you

University of Maryland, College Park

Hardware Security

285 notes

Cours 4 sur 5 dans Specialization Cybersecurity

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.

À partir de la leçon

Good Practice and Emerging Technologies

This is the last week and we will cover some positive things on hardware security. We start with trust platform module (TPM), followed by physical unclonable functin (PUF), and FPGA-based system design. We conclude with a short discussion on the roles that hardware play in security and trust.

FPGA Implementation of Crypto13:44

Vulnerabilities and Countermeasures in FPGA Systems10:22

Role of Hardware in Security and Trust5:34

Physical Unclonable Functions (PUF) Basics16:23

RO PUF: Reliability8:06

Trust Platform Module and Other Good Practices8:59

Rencontrer les enseignants

Gang Qu
Associate Professor
Electrical and Computer Engineering

Last time we talked about the advantages of using FPGA to

implement cryptosystems and hardware security primitives.

Now we discuss the vulnerabilities and

the countermeasures in FPGA-based systems and FPGA design flaw.

Most of these vulnerabilities and the countermeasures, we have seen them before.

So this can be a very good review for

what we have learned in the past five to six weeks.

FPGA systems, like other computing systems, have vulnerabilities.

There have been reported attacks from such channels and

fault injection to break FPGA systems.

There have also been attacks for all type of FPGA systems.

The SRAM based FPGAs, anti-fuse based or flash based FPGAs.

On the other hand, the design flow of FPGA system itself is not secure.

At the hardware description language design level that this

audience the designers they may still design details of

the intellectual property, or did they insert trojan into the design.

And, and trust its third-party IPs went through the similar damage.

During the synthesis process there's always the use-uh,

designers who are EDA tools, they may introduce trojan into the design.

Or they might come perform some IP piracy and

also the EDA tools needs to be protected from dishonest designers for illegal use.

And finally the FPGA configuration bitstream file needs to

be protected from being misused by users.

So next we'll elaborate these vulnerabilities and

the tags from the market view of FPGA.

In this FPGA market, there are six major players.

The FPGA vendors, those are the big FPGA companies that fir,

that produce and sell, design and sells FPGA chips.

And there are semiconductor foundries that view the chips.

And there are IP vendors built the DSP cores other intellectual properties.

There are EDA tool vendors and also there are system developers which is

which are going to develop FPGA based systems.

And eventually we have these end users who will purchase used FPGA based systems.

And there are several connections between a pair of parties.

So for example here, we have FPGA vendors with this edge.

With a single arrowhead goes to the fundraise.

This indicate a service request, which the SP vendor wants the,

their FP chips to be fabricated.

And this double error adds line indicates the return to service.

In this case, the founder will fabricate the chip.

The return to the FPGA vendors.

And we'll study each of these pair of connections and

about their vulnerabilities and the potential attacks.

The first one is between FPGA vendors and the foundry.

In this case the FPGA vendors will request some fabrication from the foundry.

And the foundry will give them the FPGA chips based on the,

the design from the FPGA vendors.

And in this case where FPGA vendors get the chip from the foundries they may not

just trust it for no reason.They may

consider whether there's any malicious things inside these FPGA chips.

For example, whether there's any hardware trojan.

Whether they leak any information during the design of FPGAs.

And also the main concern,

whether the foundry has fabricated exactly the amount of FPGA chips as requested.

Whether they have overbuilt or built more FPGA chips or not.

The second connection is between FPGA vendors and

either the EDA tool vendors or the IP vendors.

In this case the FPGA vendors, they want to put design tools and in other important

intellectual properties, like for example the DSP cores onto the FPGA chips.

And the both vendors, the tool vendors,

the IP vendors will provide such service to the FPGA vendors.

And in this case there are concerns from both sides.

The FPGA vendors will be concerned about whether the product from the EDA tool

vendors and the IP have any Trojan or not.

Whether they will leak any design information.

And also the tool vendors and

the IP vendors, they'll be concerned about how to protect their IPs.

Whether the FPGA of vendors will do reverse engineering,

then misuse their IPs.

The next connection is between the system developers and the FPGA vendors.

In this connection the system developers, they will try to buy FPGA chips from

the FPGA vendors, and then the FPGA simply missell the chips to them.

And, for for the FPGA based system developers, they will

have the concern of whether these chips they got have any hardware trojan.

Whether they will try to steal any valuable design information.

And then finally once the system developer builds the FPGA-based system,

eventually the end user will request to purchase such system and use them.

In this case, the system,

the end users when they purchase our FP, FPGA based system.

They will have to concern about the trust of such system.

Whether there's any hardware trojan,

whether it will leak any information when the user is using the system.

And from the system, the FPGA based system developer point of view,

they will consider whether these users can be trusted or not.

Whether they will go to open, perform reverse engineering and then try to

clone the FPGAs, trying to retrieve the configuration-based stream files or not.

Whether they may launch, side channel attacks, and

FPGA replay attack which will going to be discussed next.

And what we'll do now is we're going to consider each of

these possible attacks and the available countermeasures.

We start from the foundry overbuilding.

We talk about this,

in this attack, the foundries will build more chips than requested and

then keep the actual ones by themselves, or try to sell them at a lower place.

And we have discussed this before, the hardware metering technique or

remote activation technique can be used to prevent such an attack.

And the second attack is the trojan.

We have seen many many links that might be trojan.

And we discussed a lot of trojan detection and

trojan prevention techniques that can be applied in this scenario.

And those we have talked about in the testing process, how we can test.

Trying to find the existing whether there's any trojan existing in the chip.

And the second one is reverse engineering.

The reverse engineering happens at multiple levels.

It can happen at the, the hardware description language design level.

It can happen at the configuration bit stream level.

And to protect reverse engineering attack, and people can use encryptions for

the encrypt, the, the configuration bitstream file.

Or they can do obfuscation, trying to make the design harder to understand.

And the next one is the cloning attack, where after the reverse engineering.

The illegal users, they are trying to fabricate, or

trying to use the reverse exchange configuration bit

stream file to configure FPG chips, and this is what we call the clonal attack.

And we have talked about the digital watermarking and

digital fingerprint techniques to determine such an attack.

Because you have your watermark trying to prove that this is your design.

Even after they clone it, you can prove it is yours, or once you put a fingerprint,

you can tell who has done this since illegally trying to clone the chip.

And also, there are some risks to the work trying to bind.

The chip, the FPGA chip with encryption or with silicon path.

And the next one is side channel attacks.

So there have been a lot of reported successful attacks from the power channel,

from the timing channel, or from the electromagnetic,

emission channel trying to leak information from the FPGA chip.

And, the most of the passive the techniques against the passive attacks we

have discussed earlier.

Can be applied for FPG and base the system against a side channel attacks.

And then, finally, this is a new attack for FPG system.

It is called FPGA replay attack.

And what happens in this case is so, when a new or

updated FPGA chip is in the market and the taggers, they may

try to use a known vulnerabilities which are for the old systems.

And trying to see whether the newer system or

the updated systems has fixed that known vulnerability or not.

If it hasn't, then you will have a successful attack.

This type of approach is called remote update protocols,

will try to do a reconfigurable binding to against such attacks.

Explorer notre catalogue

Rejoignez-nous gratuitement et obtenez des recommendations, des mises à jour et des offres personnalisées.

Coursera propose un accès universel à la meilleure formation au monde, en partenariat avec des universités et des organisations du plus haut niveau, pour proposer des cours en ligne.

© 2019 Coursera Inc. Tous droits réservés.

Télécharger dans l'App Store

Disponible sur Google Play