I’m trying to capture some RSA traces on the XMEGA target by running the jupyter notebook in courses>sca202 and I am experiencing some problems.
The first issue I encountered was that the firmware would not compile as is. I screenshotted the error, which I was able to eliminate by commenting out any reference to those two functions in simpleserial-rsa.c (from what I understand, those functions / commands are not used in the XMEGA implementation of the firmware).
After that, the firmware would compile, but with the following warning:
With the obtained .hex loaded on the XMEGA I was able to capture these traces (using different exponents for the blue and the red one, as done in the jupyter notebook):
These traces appear similar to those obtained using the precompiled firmware downloaded with the source code (simpleserial-rsa-CW303.hex), even if shorter in length.
I have simulated the firmware in Microchip Studio to investigate the warning and it seems that the base is not initialized to the correct value (note the length equal to zero):
Also, when running the rest of the code in the simulator the value of
res does not change from “1”.
By modifing the line of code causing the warning from
const bigint_t* a = ENCRYPTED; to
load_bigint_from_os(&real_base, ENCRYPTED, sizeof(ENCRYPTED)); const bigint_t* a = &real_base;
I was able to get the correct base to be loaded and used:
Now the obtained traces are really different from the ones before and the execution times are much longer (several seconds):
Here I’m using 0x08 and 0x0c as expontents. I think that the blue trace and red trace are identical because, when using the correct base, each operation (as in square or mult) takes a lot of time and only part of the first operation is captured in the trace. Beng that for 0x08 and 0x0c the first non-zero bit is in the same position, the obtained traces are then identical.
bytearray([0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]) and
bytearray([0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0]) as exponents, it can be seen that the start of the first operation is delayed for the second exponent. This confirms, in my view, that only part of one operation is captured in the trace.
Note: when sending the p command with
bytearray([0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]) the execution time measured is 39 seconds, when sending the p command with
bytearray([0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0]) it is 16 seconds (default ADC settings). In both cases
scope.adc.trig_count return a 9 digits value.
Sorry for the lenghty post.
Am I missing something obvious about the code? If that is not the case, it looks like it’s impossible to capture a portion of RSA decryption of a plausible message on the XMEGA target, even reducing the exponent to 16 bytes.
Thanks in advance for your time