[ecdsa] Extend setup to allow for random and fixed data

[vogelpi]

FYI @bilgiday

[bilgiday]

Thanks @vogelpi.

We are almost there, I just need to change a few things in the capture.py and the ecdsa config files. I will take a look at it today, and update the issue.

[bilgiday]

@vogelpi @vrozic @johannheyszl

An update for the capture side: There are two main SW-related items on the capture side.

1. Sending all the secret shares from the Python code (capture.py)

• Our current implementation supports sending only single shares of private key d and secret scalar k from Python to C code.
• I just prepared two draft PRs to enable us to send the following parameters from Python to C (d0, d1, k0, k1).
  [ecdsa-sca] Enable ECDSA-256 secret shares for capture #109
  [otbn/sca] Add new sca features for otbn_ecdsa_256 opentitan#16899
• In the ot-sca PR, we have a capture command, ecdsa-simple to run ECDSA-P256 and collect traces. I think we can create new commands by using this template. As far as I understand from the previous AES and KMAC commands, just copying this template command and changing the input-setting part would be sufficient for most of the cases
• Please comment in the PRs for specific implementation ideas.

2. Improving the performance of the setup

• In our current setup, we need to reset the FPGA for every section of the ECDSA. For example, I need to run the ECDSA 52 times to collect a full ECDSA-256 trace. With our current setup, I can only collect 10 full ECDSA traces per hour. This is not good, especially for vertical attacks.
• To solve the issue, I tried to use CW-Husky's streaming mode but it limits the resolution to 8 bits, which wasn't good enough for me to see the patterns on the power trace (I have a command, ecdsa-stream in the capture.py).
• I am planning to explore a new CW-Husky feature, segmented capture, to see if it can help us: https://www.crowdsupply.com/newae/chipwhisperer-husky/updates/new-feature-segmented-capture
• Until we have a permanent solution, for vertical attacks, focusing on only a few sections of the ECDSA may enable us to collect more traces per hour.
• I will update the issue if I can make progress on the segmented capture.

[bilgiday]

By the way, while looking at the segmented capture, I encountered this set of demos from NewAE. Here, there are a lot of useful stuff, dropping the link here as a reference:
https://github.com/newaetech/chipwhisperer-jupyter/tree/master/demos/CW305_ECC

[colinoflynn]

If you need some additional features on the CW-Husky, @jpcrypt could comment on effort level of supporting that (especially w.r.t. question of streaming a higher bit-depth)

[jpcrypt]

@bilgiday just in case it's not clear, you can use streaming mode with either 8 or 12 bits/sample; the maximum sampling rate scales linearly. In my experience, with one sample/clock I can get 16 MS/s in 12-bit mode, 24 MS/s in 8-bit mode. You can squeeze a bit more if the capture size doesn't exceed the FPGA storage size by "too much", but there's no formula for this; you have to go by trial and error.

The segmented capture could definitely be useful here, if you only need a subsets of the full trace at regular intervals (i.e. X samples every Y cycles repeated Z times). If X*Z < 128K samples, then you don't need streaming and are no longer subject to its sampling rate limitations. CW305_ECC notebooks show an example of this (get_trace_segments()). Let me know if you need help getting going with it.

[bilgiday]

Thanks @colinoflynn, @jpcrypt for chiming in.

It is good to know that I can play with the resolution in the streaming mode. I will try different resolution and sampling frequency values to figure out what I can get from my local setup.

[bilgiday]

An update:

• I tried @jpcrypt's suggestion, and verified that on our CW310, we can use the streaming mode with 12bits/sample resolution at 15-20MS/s sampling rate. With this approach, it takes ~8s to collect a full ECDSA-256 trace (previously, it was taking ~360s with the iterative ecdsa-simple capture command)
• Previously, we needed to reset the FPGA for every trace; it seems it was related to OTBN codebase. That problem is also solved now. With these new PRs, we don't need to reset the device for each trace, which will improve the performance of capture campaigns.
• I updated the PRs, and you can capture ECDSA-P256 traces using the following commands ECDSA-256 using the following two commands (ecdsa-stream is the faster one)

./capture.py --cfg-file capture_ecdsa_cw310.yaml capture ecdsa-stream --num-traces 1 --plot-traces 1
./capture.py --cfg-file capture_ecdsa_cw310.yaml capture ecdsa-simple --num-traces 1 --plot-traces 1