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...

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.

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.

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 ;-)

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?

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.

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.

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.

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...

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!

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