I have set up my own CPA attack on a cryptographic algorithm, using the CW-Lite capture board and stm32f3 target on a CW308 ufo board. While capturing traces, something strange happens.
I capture traces using the cw.capture_trace(…) function in a loop. In the 20th loop, while capturing the 20th trace, I get the warning "(ChipWhisperer Target WARNING|File SimpleSerial.py:410) Unexpected start to command: ", and the capturing halts.
The simpleserial commands inside the cw.capture_trace(…) function are the same in each loop, so I don’t understand why this happen at the 20th loop.
Any idea what might be the problem? Thanks in advance!
It sounds like your target (I’m assuming this is your own target FW, not from our examples?) starts behaving differently; the error means that the target didn’t return a response starting with “r”, as it normally should.
In this case it sounds like the target isn’t sending anything back at all – is it stuck? Does it need a reset to recover or does the next
Using a debugger might be helpful towards figuring out what’s happening.
Yes, I have my own target FW. It seems like the response is empty, since it says "Unexpected start to command: ". Nothing more happens, and the only way out is a reset. So I also believe it is stuck, but don’t understand why. The only thing it does is to decrypt a single Kyber ciphertext (one for each capture_trace()), plus some small additional calculations. For each capture_trace(), the variables on target are overwritten (except the key), so can’t see that there is a memory issue either.
I have tried to give the target less and more to work with for each capture, to see how this affects the behavior. After stripping down the target FW to a a single Kyber decrypt function call, it reaches 42 traces captured before it gets stuck.
Is there a simple way to reset the target for each capture? If so, I would have to send the target some additional data for each capture, but maybe that’s the only way.
Yes - if you ran
Setup_Generic.ipynb to connect (like all our examples do), then you can call
But if it was me I’d really want to figure out why the target gets stuck…
Ah, I found the source of the problem. I used the Kyber implementation from the pqm4 library, but with an old checkout. I tried a newer version, and the capturing runs perfectly well. Must have been some bugs in the older implementation