Home > Tracks > Embedded Systems Security

Hardware Hacking: Hands-On

Colin O'Flynn - Watch Now

Designers releasing embedded devices need to understand what sort of hardware attacks they will face in the field. We will discuss how two different types of advanced attacks work: side channel power analysis and fault injection. Not limited to theory, we will demonstrate how they are used in practice and work through real products the attacks have been used on. Low-cost tools and open-source material will be highlighted, so the attendee can learn more details & even perform these attacks themselves.

M↓ MARKDOWN HELP
italicssurround text with
*asterisks*
boldsurround text with
**two asterisks**
hyperlink
[hyperlink](https://example.com)
or just a bare URL
code
surround text with
`backticks`
strikethroughsurround text with
~~two tilde characters~~
quote
prefix with
>

Justin
Score: 0 | 5 months ago | 1 reply

Amazing talk Mr. O'Flynn! DPA also sounds like a good way to verify IP infringement. This certainly gave ideas on possible silicon implementations that can combat DPA, hehe. Come to think of it, is EM injection effective against ICs that are radiation resistant? (have you ever tried it on such a product?)

Colin_OFlynnSpeaker
Score: 0 | 5 months ago | 1 reply

I haven't tried on rad-hard stuff - would be interesting to do so! AFAIK buying normal(ish) rad-hard devices isn't as easy as just getting off digikey ;-) I've tested on automotive for example and they work OK with fault injection, and they are normally on larger processes with some level of resistance against high EMI noise. With some devices you can blow them up with EM glitching, so I suspect it's still strong enough...

Cesar_Santos
Score: 0 | 4 months ago | no reply

As a follow-up on that question, around minute 57 you mention something about "ChipArmor project you are starting". What will this be about? Any expectation on when this will become public? :)
And thanks for the great presentation! This actually complements lots of presentations we had here in the conference regarding secure design.

JorgeCifuentes
Score: 1 | 5 months ago | 1 reply

Which are the best PCB locations for inserting voltage glitches?

Colin_OFlynnSpeaker
Score: 2 | 5 months ago | no reply

Depends! Most of the time you want to be close to the IC power pins to ensure you have a low-impedance path and get the fastest transitions.

Mehdi
Score: 2 | 5 months ago | 1 reply

Thanks for the presentation.
I have 2 questions:

1- How much do you think one can benefit from software security experience, in the hardware security world? Put another way: other than the different skillsets (electronics, hardware protocols, etc), what are the big differences from a process/methodology perspective between the software security and hardware security? (from both sides: secure design, and offensive attacks)

2- What are the highest-priority security features and threats one should pay attention to, when designing a critical embedded hardware system? (say an automotive ECU)

Colin_OFlynnSpeaker
Score: 1 | 5 months ago | no reply

Hi Mehdi,
1: There's a lot of overlap, and in fact the majority of "attacks" happen at the intersection. Software security assumes something in hardware is more secure than it is for example. The flip side also happens - it's not unusual to see a super-secure microcontroller/secure element used incorrectly, resulting in an "easy" attack that makes the secure element irrelevant.

So knowing both is an asset - likewise if you come from security in one space (say having done lots of SW security work before), you're going to come at the hardware security side with a lot more inherent knowledge about where issues "could" be and where the most effort should be spent (on either attacks or defense).

2: Checking manufacture assumptions is pretty critical. For example - if you're using a device with a simple read-out or fuse protection (such as the LPC1114 I show in the demo), anything you do on top of that is going to be useless. But if you chose a microcontroller that has a "secure storage", where a private key can be stored in a way that isn't directly accessible (lots of them have such feature now) you've got a few more layers of defense. Of course you might want to spend effort validating the secure storage.

But even asking the question "what if claimed feature X can be bypassed" (ask this about say secure vs. non-secure operating modes, fuse bytes, encryption engines, etc) gives you a good feeling. If the entire system has that single point of failure, you know there's a huge risk there, so either use a different solution or validate that failure point.

alexanderentinger
Score: 3 | 5 months ago | 1 reply

I've always considered power based side-channel attacks as something requiring sophisticated tools and arcane setups and therefore quite unlikely to happen. This presentation has been an eye-opener for me, thank you very much for given an easily understandable presentation on this subject.

Colin_OFlynnSpeaker
Score: 3 | 5 months ago | 1 reply

Thanks! It's definitely a lot easier than most people realize - I found part of the problem is a lot of the background was written for more academic audiences, so I think lots of engineers would skip it. I started the project back when I learned about the attacks, and my immediate thought was "nah it's too complicated, this won't work in real life". Anyway turns out I was wrong, so now trying to help overs avoid my mistake ;-)

alexanderentinger
Score: 1 | 5 months ago | no reply

Apparently so ;) Thank you very much for your effort, keep up the good work! ;)

CullenMoMullen
Score: 1 | 5 months ago | 1 reply

Have you had success in enabling disabled features on SoCs where tiered chip offerings disable features at different price points especially through laser fuses?

Colin_OFlynnSpeaker
Score: 1 | 5 months ago | no reply

Haven't looked at that! Normally the fuses (at least e-fuses) get latched at power-on due to higher current involved in the read (or risk of 'reclosing' them)... in which cause you can glitch the read or latched value. So it's possible it would work, any good examples of parts?

Matt_Liberty
Score: 1 | 5 months ago | 1 reply

Excellent talk and demos, Colin. Have you used the existing Chipwhisperer software to attack the XChaCha20 style-ciphers?

Colin_OFlynnSpeaker
Score: 2 | 5 months ago | 1 reply

Not yet unfortunately! We haven't run full attacks on ARX style ciphers at all (on the list...). I had wanted to try and implementing the attack from https://eprint.iacr.org/2017/1021.pdf which had a nice level of detail. They do mention that depending on usage it can make the attacks moot, so it's a good example where knowing the attacks exist early on helps you make better choices.

Matt_Liberty
Score: 1 | 5 months ago | no reply

Thanks for the paper! I'm a little conflicted on wishing you success ;)

CullenMoMullen
Score: 2 | 5 months ago | 1 reply

How best can secret keys be adequately protected on Manufacturing line when most systems are integrated into the Shop Floor Control?

Colin_OFlynnSpeaker
Score: 1 | 5 months ago | no reply

I don't have experience with the products so can't personally recommend different ones - but a few people sell 'secure provisioning' boxes that help to burn fuses/key material into devices (see https://quartermaster.dev/ for example). You can also often architect your system such that the devices themselves can do the majority of this work - Microchip has a talk here actually on using their ECC608A key for example, which I expect covers some of this (haven't watched full thing yet). The nice thing is the secret keys get generated "on device" so you need to trust manufacture a lot less... still concern around how you track number of "authorized" devices, but it eliminates a lot of risk if you can avoid needing to let someone else handle some master secret. You may still want a "secure box" in the manufacture as part of this, but the risk of compromise is a lot lower.

CullenMoMullen
Score: 2 | 5 months ago | 1 reply

Wouldn't switching from 0-1 and 1-0 be roughly equivalent? Power wise?

Colin_OFlynnSpeaker
Score: 1 | 5 months ago | no reply

Yup! In fact if you look at some of the power traces you can see the difference here due to the rail the power is coming from. So a shunt in VCC will capture the 0-->1 transition, since the data bus line is getting charged from the VCC line. But a 1-->0 means charging the bus like to GND, so you see some current from that shunt.

DrewFustini
Score: 1 | 5 months ago | 1 reply

How can you tell the order of bits on the bus with DPA?

Colin_OFlynnSpeaker
Score: 0 | 5 months ago | no reply

You can't really ;-)
With classic DPA though you basically just declare which bit you will "target". So say I'm looking at bit 0 - in fact my measurement is all the bits at once. But the remaining bits that we aren't "targetting" will look like random noise. If you imagine a single bit on the bus "stuck" at 0 say, and you take 1000 measurements, then compare that to measurements with the bit "stuck" at 1. There should be a minor power difference between those groups, because the remaining bits are random (we are assuming here).

Can see a step-through here of the classic DPA attack: https://github.com/newaetech/chipwhisperer-jupyter/blob/master/PA_DPA_3-AES_DPA_Attack.ipynb . This talk had a very high-level overview due to time! I think I've got some other videos that work on side-channel in more detail...

DrewFustini
Score: 0 | 5 months ago | 1 reply

How do you control the precharge? (At 21 minutes mark)

Colin_OFlynnSpeaker
Score: 0 | 5 months ago | 1 reply

The pre-charge is basically a side-effect of most microcontroller bus designs. Basically consider an 8-bit bus, the worst case situation is if all lines switch from 0 to 1 (8x (1-0)).. You can help alleviate some of this by going to the 0.5 state ('pre-charge') state, in that same example of all lines going 0 to one it becomes 0-->0.5-->1.0. Each transition is only 8x 0.5, and then it's spread over a longer time.

If we're not talking a "main bus", such as a small crypto accelerator where we target an internal bus/state, they won't have a pre-charge. In which case you use a model that matches, and actually looks for power related to the changes, and not the "absolute hamming weight".

Let me know if doesn't make sense!

DrewFustini
Score: 0 | 5 months ago | no reply

Hi Colin! Great presentation!
Does this mean that the attacker controls the external data bus design and therefore can force the per-charge to happen when lines are driven high or low?

CullenMoMullen
Score: 1 | 5 months ago | no reply

Excellent talk Colin!!

CullenMoMullen
Score: 0 | 5 months ago | 1 reply

Crypo cache footprint same why?

Colin_OFlynnSpeaker
Score: 0 | 5 months ago | no reply

Which footprint sorry - not sure what the reference is for!

Colin_OFlynnSpeaker
Score: 2 | 5 months ago | no reply

Hi this is Colin, you might know me from hits such as the video slightly higher up the page. If you've got question related to anything in the talk please let me know and will try to answer here!

OUR SPONSORS