Acquisition patterns, AcquisitionController limitations

Let’s suppose that I’m measuring power consumption of a device which I cannot interact with. Having acquisition pattern in such case seems redundant (trace config file with misleading data, a lot of useless numpy files created). One way around I see is to create stubbed class in acq_patterns directory but still AcquisitionController will attempt to send data I’m not using - plaintext and key. Am I right? Current AcquisitionController looks limited to me. What if in future I would like to send more complex data, for example curve parameters for ECC?

I think that AcquisitionController class should be better separated from, user-controlled acq_patterns modules. What is your view on this? Also one side-question. Is Newae open to community code contributions?

Best regards,

Adam, you’re right - the acquisition controller was definitely designed with AES in mind.

  • If you have a device that you can’t interact with, then all of the plaintexts and keys are useless. This means that you really don’t need all these redundant files. However, keep in mind that the traces are the bulk of the results - looking at a random project folder, my trace file is 37.5 MB, and my plaintext/key files are 3 KB. I’m also curious about what you plan to do with just the traces! It’s tough to analyze them if you don’t know what the device was doing.
  • For other types of encryption, the current controller looks a bit limited. You can add a lot of your own functionality in the target code, though. For example, with ECC, you could make a new ECC target class that keeps track of which curve to use and sends this curve to the device before a capture. It does feel like a bit of a hack, though.

We’re definitely open to community contributions - we actually just swapped things around so our main working repository is on GitHub instead of Assembla.

You are probably right, having no interaction with device under test doesn’t make much sense. Real life example where having empty acq pattern would by useful is having communication responsible tool separated, lets say already written in other language, where chip-whisperer would by only integrated as trace acquisition tool. Also thanks for ECC tip.