Power fingerprinting of a microcontroller

[masoudium]

Hi,
I'm into a project, the purpose of this project is to find out if there is any relation between consumption power and execution path of a device like PLC that has a periodic execution path.I know people have work in this field and there is a company named PFP Cybersecurity which provides IDS based on power consumption of a device.

I've tried a few ways up to now to measure the consumption current of a 24V powered PLC.
First I tried to use and avr and a shunt resistor to measure voltage across this resistor but the result was not satisfying. 
In my second try I used a module called INA209 a high-side shunt current measurement module  with I2C interface, the measurements was more accurate but I think I'm missing some samples as I was capturing only 200 samples per second and the PLC Micro-Processor works at least at 16Mhz.
At my last try I bought a Digital Oscilloscope, but still I can't measure current change of my PLC.

I appreciate any solutions to measure the consumption current of a PLC accurate( in range of mili-amps or 100 micro-amps)and fast enough(fast to capture every instruction executed in PLC).

[rs20]

You need to quantify your problem before trying to solve it. What sample rate do you want? What is the size of current you're trying to measure? What size changes in current do you need to be able to see? Have you tested that your solutions measure current properly, before leaping into trying to measure consumption of a PLC?

You may have trouble measuring fluctuations in the 24V power input, as there's obviously going to be an enormous amount of decoupling and filtering before you get down to the core microcontroller running at 5V or less.

[Rerouter]

Normally devices intended to figure this out will piggyback the device under test, having measuring points on the desired power rails right at the pins, or very close to it, measuring faster than the original device, sometimes removing local decoupling to make the current spikes louder,

A number that i have seen either gave an output to supply the device a clock, (so that they could stretch it while figuring out the mapping) or connected directly to the osc out pin to measure and correlate in step with it, (the operations inside the device may not be syncronous to the clock, and spikes may occur in sequences as the signals propgate through the circuitry,

200Hz bandwidth will probably tell you when it changes I/O state, generally the piggyback device is quite a bit more powerful than the device under test so this kind of stuff can be processed as close to real time as possible, meaning your going to want atleast 16Mhz, more likely something closer to 200Mhz if you want to figure out what spike correlates to what op code.

[masoudium]

Oh thanks guys on your great advices. But let me explain what is in my mind more accurate. I'm trying to test the firmware part of the PLC that handles the communication of the device. I'm trying to use an approach called fuzzing to send malformed and abnormal frames to a device with the purpose of crashing it.
I guess errors such as misusing of memory like buffer overflows or control flows may have a good impact on the consumption current of the device, That is what I'm trying to find out, using side channel data to find software bugs in the implementation of the communication protocols of a PLC.

Now do you have any advice how I can approach this test?

[rs20]

1. In my head, I cannot contrive a situation where a fuzzed packet causes a clearly unusual power consumption measurement, but the controller still persists to appear to work normally. Hence, I suspect a functional test that sends a bunch malformed packets, and then runs a standard test routine, would be much easier and much more likely to be successful.

2. If you want to persist with monitoring consumption current of the microcontroller, I repeat the recommendation already made: You need to measure the current going into the microcontroller, not the entire PLC. Measure the current consumed by the microcontroller (break the VDD trace), and then select a resistor value that produces are certain, acceptable V=IR drop when placed inline. Then use a uCurrent to boost the reading nicely, and feed that into an oscilloscope.

Remember to not blow up your oscilloscope, see the EEVBlog video "how not to blow up your oscilloscope". In short, connecting the ground clip to one side of the resistor will cause all sorts of problems. So the PLC will need to be floating, or you'll need differential probes, to perform the measurement.

[3db]

Have a look at the Youtube channel  https://www.youtube.com/user/micahjd/videos
Mica has done some videos on this subject.

3DB