Add support for CW-Husky

[lowrisc]

Add support for CW-Husky

[colinoflynn]

I've also started adding some documentation here: https://github.com/newaetech/ot-sca/blob/cwhusky-doc/doc/getting_started_bergen.md

I'm using a separate branch for now to avoid polluting the active PR. If the documentation is done before that PR gets merged I'll move it over, but for now the commits will be a bit messy on the cwhusky-doc branch. However I wanted to get some notes out there ASAP, and if there is anything else useful please feel free to push into that.

[colinoflynn]

Some initial support being added at https://github.com/newaetech/ot-sca/tree/cwhusky-support - currently the script will autodetect CW-Lite vs. CW-Husky. I get a reasonable looking graph but there is an error raised as well (by the husky), but in case anyone is looking at this it should have the needed framework.

Will update this when fully working.

As a note - the CW-Husky changes have been coming quickly on the ChipWhisperer branch, so you'll need to checkout the latest develop and be sure to do the FW Update on the CW-Husky.

Here is what it looks like (one zoomed in):

[vogelpi]

Nice, thanks @colinoflynn ! This is for sure relevant for @m-temp who also started to look into Husky.

[colinoflynn]

A few more fixes were pushed by @jpcrypt - traces look OK & we are hitting around 1400-1700 traces/sec. Tuning may be needed for husky itself (i.e., different input settings) but otherwise the actual code seems to be working there. Testing with 2M traces byte 0 is always recovered, different settings for ceca.py give potentially useful results but didn't do much testing there (I misunderstood output on first look, best case I got was Recovered 66/120 differences between key bytes).

[colinoflynn]

I was too fast to dismiss this. Using ./ceca.py -f projects/opentitan_simple_aes.cwp -a 505 520 -d output -s 3 -w 16 -n 2000000 recovers the key on CW-Husky w/ 2M traces. This is again with masking off (.masking = kDifAesMaskingForceZero). The output looks like this:

INFO:root:Will use 1962961 traces (98.1% of all traces)
2021-10-23 13:19:19,846 INFO ceca.py:520 -- Will use 1962961 traces (98.1% of all traces)
INFO:root:compute_pairwise_diffs_and_scores took 0.4s
2021-10-23 13:19:21,115 INFO _timer.py:61 -- compute_pairwise_diffs_and_scores took 0.4s
INFO:root:Difference values (delta_0_i): [  0 196  41 120  25  62 245  89  49 239 220  24 102 179 220 118]
2021-10-23 13:19:21,116 INFO ceca.py:528 -- Difference values (delta_0_i): [  0 196  41 120  25  62 245  89  49 239 220  24 102 179 220 118]
INFO:root:Recovered AES key: 2b7e151628aed2a6abf7158809cf4f3c
2021-10-23 13:19:21,158 INFO ceca.py:532 -- Recovered AES key: 2b7e151628aed2a6abf7158809cf4f3c
INFO:root:Recovered 82/120 differences between key bytes
2021-10-23 13:19:21,159 INFO ceca.py:538 -- Recovered 82/120 differences between key bytes
INFO:root:perform_attack took 13.6s
2021-10-23 13:19:21,159 INFO _timer.py:61 -- perform_attack took 13.6s
INFO:root:main took 14.7s
2021-10-23 13:19:21,159 INFO _timer.py:61 -- main took 14.7s

EDIT - play around it seems to work down to 1.2M traces. I haven't done much tuning though of parameters besides checking the above and looking for it to recover the key.

[jpcrypt]

One thing to note for cases like this where you are looking at power samples in narrow windows is that the Husky ADC's latency is different from the CW-lite/pro ADC's latency: Husky latency is 3 cycles less. You can compensate for this with scope.adc.offset = 3, or shift your attack window accordingly.

[vogelpi]

This looks really great! Also because with Husky we can use the latest ChipWhisperer version and experiment with different data formats such as int16 vs. double to capture more traces (newer ChipWhisperer/Firmware versions seemed to break segmented capture with the CW-Lite).

I think the results you got look quite okay. I will try to record another trace set with the current bitstream on the CW310 and the CW-Lite tomorrow. You can then use that to compare/tune the two scopes.

Regarding the tuning of parameters: can you elaborate a bit on what parameters can be tuned? Do you mean the gain etc?

[vogelpi]

Btw @colinoflynn @jpcrypt , I have a little script here that allows sweeping the attack window and the number of traces for ceca:

vogelpi@fbd0a24

First you need to tune the attack window with a command like this:

./sweep_ceca.py -f opentitan_simple_aes.cwp -s 3 -w 16 -d output -n 500000

This will tune based on using 500000 traces. You can change the variables start_sample_min/max/step to control the sweeping.

Then if you have the window, you can run:

./sweep_ceca.py -f opentitan_simple_aes.cwp -s 3 -w 16 -d output -a 518 527

To sweep the number of traces used.

This allows you to generate curves like this:

[colinoflynn]

Newer ChipWhisperer/Firmware versions seemed to break segmented capture

Ah sorry that was my fault - segmenting seemed to break the FPGA bitstream so we had done a quick turn-off, I've meant to rebuild that. FWIW this won't be an issue w/ CW-Husky as the entire FPGA design is correctly constrained (the CW-Lite was pushing some items beyond their limit), so there is a lot of good reasons to move to CW-Husky for future...

can you elaborate a bit on what parameters can be tuned? Do you mean the gain etc?

Yes - basically just the gain. There could be some clock offset stuff but I think gain is the main one.

I have a little script here that allows sweeping the attack window and the number of traces for ceca

Perfect - that is much better than my "script" (which just spit out the ceca.py call with parameters). And we're getting cold weather here so perfect time for our CPUs to be keeping us warm. It looks like the 506 -- 519 window is optimal (14 window size) for my run. I'll confirm with some gain changes what a sane default is.

Once that is done - do you want us to PR these changes, or for someone to pull them into their branch for testing and PR from there? Do you also want a separate cw_litw/cw_husky name rather than auto-detecting? I'm guessing at some point changing cw305->cw310 is also needed fore naming.

[vogelpi]

Thanks for getting back @colinoflynn .

No worries about the segmented capture on the CW-Lite. It was really very useful in the last couple of months (we managed to keep it working by fixing the ChipWhisperer version) but it's clear that Husky is the better choice. We will switch to that.

If you could do a PR this would be great. I would then test and review it. Auto-detection seems fine for me. My plan is to keep the cw305 around for some time. For AES it's still a good choice as there seems to be less noise compared to the cw310.

[colinoflynn]

I'll leave gain out of the PR since it's in the .yaml file and not sure best way to specify for different hardware. But FYI with a gain of 35 I get the following output for the previously mentioned points:

#traces
          key recovered
            #diffs recovered
    10000 0   1
   100000 0  13
   200000 0  48
   300000 0  60
   400000 0  69
   500000 0  71
   600000 1  76
   700000 1  83
   800000 1  82
   900000 1  88
  1000000 1  88
  1100000 1  91
  1200000 1  91
  1300000 1  92
  1400000 1  92
  1500000 1  96

My plan is to keep the cw305 around for some time

Ah sorry - I meant just renaming the directory so it was clear to new users it applies to both!

On the final PR I've changed cwlite to just 'cw' in some of the classes & on the capture app options, again to avoid confusion (I hope). But feel free to remove that part as it's just one commit so easy to skip the rename. PR shortly...

[vogelpi]

Just to be sure, what bitstream did you use? The one in ot-sca? With that bitstream and the CW-Lite (gain 34.5) I get the following:

./sweep_ceca.py -f opentitan_simple_aes.cwp -s 3 -w 16 -d output -a 518 527
#traces
          key recovered
            #diffs recovered
    10000 0   2
   100000 0   1
   200000 0   7
   300000 0  14
   400000 0  38
   500000 0  61
   600000 1  82
   700000 1  94
   800000 1 103
   900000 1 109
  1000000 1 108
  1100000 1 113
  1200000 1 115
  1300000 1 112
  1400000 1 114
  1500000 1 114
  1600000 1 118
  1700000 1 118
  1800000 1 120
  1900000 1 119
  2000000 1 119

For the gain, I did take around 5000 traces and tune it such that the max amplitude is above 0.4 but below 0.45. I would expect the Husky to give better performance but the variation with the bitstream is big.

My plan is to keep the cw305 around for some time

Ah sorry - I meant just renaming the directory so it was clear to new users it applies to both!

On the final PR I've changed cwlite to just 'cw' in some of the classes & on the capture app options, again to avoid confusion (I hope). But feel free to remove that part as it's just one commit so easy to skip the rename. PR shortly...

Ah now I understand. :-) Changing cwlite to cw is completely fine. We have planned to restructure a bit the directory structure and with that should also modify cw305. No need to change that in your PR.

[colinoflynn]

Just to be sure, what bitstream did you use? The one in ot-sca?

Yes - this is with the bitstream in the repo. I'll have to check again with my same board but on a CW-Lite to see how it compares. The gain I used left some headroom still (I think peaks were closer to ~0.3) so perhaps that does need more optimization.

[m-temp]

We have planned to restructure a bit the directory structure and with that should also modify cw305. No need to change that in your PR.

That's something we should definitively do.
Additionally, there seems to be some miss-configuration (on my side?) between git and git lfs:
When using the binaries from e64e76d I get ValueError: Invalid file size: 41
An additional git lfs pull provides new (?) different (?) binaries, that are marked as modified. However, I am not able to attack them. (0 to2 diffs recovered) Are they masked?

I would expect the Husky to give better performance but the variation with the bitstream is big.

Building my own unmasked aes_serial_fpga_cw310 from lowRISC/opentitan@1b73f80 and using a scope_gain of 35, I get the following:

./sweep_ceca.py -f projects/opentitan_simple_aes.cwp -s 3 -w 16 -d output -a 518 527
#traces
          key recovered
            #diffs recovered
    10000 0   0
   100000 0  14
   200000 0  52
   300000 0  80
   400000 0  93
   500000 1 104
   600000 1 110
   700000 1 112
   800000 1 111
   900000 1 114
  1000000 1 114
  1100000 1 116
  1200000 1 118
  1300000 1 119
  1400000 1 117

(Ran out of memory for more traces)

However, I have the impression that the measurements are not very reliable/reproducible. I have to explore this a little bit more.

[vogelpi]

I am closing this issue as the PR for enabling CW-Husky has been merged a while ago already (#56 ). Btw, I've finally managed to try it out and it's great. I am really happy to have it, thanks @colinoflynn and @jpcrypt !