Comments (15)
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.
from ot-sca.
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):
from ot-sca.
Nice, thanks @colinoflynn ! This is for sure relevant for @m-temp who also started to look into Husky.
from ot-sca.
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
).
from ot-sca.
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.
from ot-sca.
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.
from ot-sca.
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?
from ot-sca.
Btw @colinoflynn @jpcrypt , I have a little script here that allows sweeping the attack window and the number of traces for ceca:
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:
from ot-sca.
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.
from ot-sca.
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.
from ot-sca.
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...
from ot-sca.
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.
from ot-sca.
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.
from ot-sca.
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.
from ot-sca.
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 !
from ot-sca.
Related Issues (20)
- [scope] Fix WaveRunner sampling rate configuration
- Fix path imports
- [uJSON] Delay between commands
- [uJSON] Single uJSON binary
- [ci] Extend CW305 CI tests
- Port CECA script to new Trace DB
- [capture] CW databases broken HOT 4
- [capture] Re-add range / saturation checks for Husky HOT 2
- [capture] Auto-compute number of segments for Husky
- [tvla] aes-specific plotting function broken
- [capture] AES masking off feature is not working properly
- [ci] SHA3 captures seem to be broken/flaky in CI HOT 2
- [tvla] Loading `ttest_step_file` for replotting figures is broken
- [ci] Add more TVLA tests HOT 1
- [db] Trace DB performance improvement
- [scope] CW-Husky USB blocked after power-up HOT 2
- Streamline TODO comments
- Use earlgrey_es_sival opentitan branch
- Print plot crashes when printing single trace
- Generating English Breakfast Binaries for CW305 HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from ot-sca.