CW305 working attack

sonersec · May 4, 2020, 7:04pm

I have a device that uses 35T firmware but I failed when it implements attacks like in tutorials. My implementation even can’t crack the key after 50000 plaintexts. Can you please help me about this problem?

jpthibault · May 4, 2020, 8:08pm

Which version of CW software are you using?
If you’re not using the latest release then there may be a bug in the attack code; it was fixed by this commit. This fix is included in the latest release.

Jean-Pierre

sonersec · May 4, 2020, 8:22pm

I am using lastest version. I installed last week and I am updated using git update.

sonersec · May 4, 2020, 8:25pm

It is v5.1,2. Is it correct?

jpthibault · May 5, 2020, 1:56am

If you’ve installed the latest release, or pulled and updated either the develop or master branches, then you should have the fix I referred to. However the version reported should actually be 5.1.3 – I’ll assume that’s a typo on your part.

When you say the attack isn’t working, are any of the key byte guesses correct?

There is another issue you may be running into: projects with more than 10k traces don’t get properly saved. The fix for this is on the develop branch:

github.com/newaetech/chipwhisperer

Project segment bug: traces beyond the segment length do not get saved.

opened 04:03PM - 29 Jan 20 UTC

closed 04:05PM - 13 Feb 20 UTC

jpcrypt

bug

When adding traces to a project with `project.traces.append()`, traces beyond th…e default segment length of 10000 will not get saved. After 10000 traces a new segment is created, but in the .cwp project file, the new .cfg is the same as the previous one: ``` Trace Management] tracefile0 = Tutorial_HW_CW305_lots_traces_data\traces\config_2020.01.29-09.38.03_.cfg enabled0 = True tracefile1 = Tutorial_HW_CW305_lots_traces_data\traces\config_2020.01.29-09.38.03_.cfg enabled1 = True ``` Unfortunately, `len(project.traces)` suggests that all traces are there, but `project.traces[x]` is the same as `project.traces[x+10000]`. A temporary workaround is to increase the segment length to the number of traces one wants to capture, for example: ``` project.traces.seg_len = 30000 project.traces.seg_ind_max = project.traces.seg_len-1 ``` However this is not ideal and can degrade performance.

Jean-Pierre

sonersec · May 5, 2020, 2:17am

In never finds any key or subkey, even it is not close. I investigated the traces and it look fine. I tried 5000 pt and it could not find also.

coflynn · May 5, 2020, 2:22am

Also what do the correlation #'s look like (maybe copy the table or screenshot if possible?). And what do the traces look like visually, similar to the tutorial examples?

sonersec · May 5, 2020, 2:37am

jpthibault · May 5, 2020, 2:40am

…and what if you use the last_round_state_diff leakage model instead? I assume it still fails but what does the table look like then?

sonersec · May 5, 2020, 2:47am

sonersec · May 5, 2020, 2:59am

jpthibault · May 8, 2020, 3:12am

Sorry for the delay, just now getting around to double-checking that the notebook works for me (it does).
Your screen shot of the PGE with the last_round_state_diff model actually shows the correct answer in the first row – it’s just not recognized as the right key by the attack. See what I get:

This is exactly the bug I first mentioned (Fix PGE calculation and known key highlighting. · newaetech/chipwhisperer@76cfb84 · GitHub)
Somehow you’re not running the version of CW that you think you are.
One way this can happen is if you have multiple installations lying around.

Run this on your end to confirm where CW is being pulled from:

import chipwhisperer as cw
cw.__file__

then refer to the installation instructions to fix as required.

Hope this helps!
Jean-Pierre