Hello,
I would like to execute a signing process on a a chipwhisperer cw308 (with an STM32F3 target board), however the secret key is around 600 kilo bytes.
Is there a feature in the simpleserial protocol that provides this? or should chunk the key in part?
Best,
Sou
No, youâll have to send it over in several chunks, the UART buffers canât hold that much data at once.
The maximum message size depends on which version of SimpleSerial youâre using:
Thanks,
I am sending two chuncks of 32 bytes in a loop from my jupyter notebook as the following:
target.simpleserial_write(âpâ,bytearray(encoded_chunk) )
In my c file I wrote:
> int main(void)
> {
> platform_init();
> init_uart();
> trigger_setup();
>
> /* Device reset detected */
> putch('r');
> putch('R');
> putch('E');
> putch('S');
> putch('E');
> putch('T');
> putch(' ');
> putch(' ');
> putch(' ');
> putch('\n');
>
> simpleserial_init();
> #if SS_VER == SS_VER_2_1
> simpleserial_addcmd(0x01, 5, Fault_Injection);
> #else
> simpleserial_addcmd('p', 64, Fault_Injection);
> #endif
> while(1)
> simpleserial_get();
> }
I have the however the error
WARNING:ChipWhisperer Target:Unexpected end to command: 2
ERROR:ChipWhisperer Target:Ack error: D002
Also the target board answer is empty
Whatâs the size of encoded_chunk
?
simpleserial_addcmd('p', 64, Fault_Injection);
means your target will expect a message of âpâ followed by a bytearray
of 64 bytes. If you send it p<32 bytes>
times two, it wonât respond.
Have a look at how this is done in https://github.com/newaetech/chipwhisperer/blob/develop/hardware/victims/firmware/simpleserial-aes/simpleserial-aes.c, for example, and how our AES attack notebooks communicate with this target.
Jean-Pierre
Hi Jean-Pierre,
Actually I would like to send a key that has 512 bytes. As I understood I need to split the key in chunks and send it. So, I chose each chunk size to be 128 bytes, hence I need to send four chunks to the victim board. My simpleserial version is SS_VER_1_1.
I used the aes code you sent to implement a function getkey
uint8_t get_key(uint8_t* k, uint8_t len) //len =128 bytes
What I understood is, as the key is in chunks I need to send from my jupter terminal
target.simpleserial_write('k',bytearray(encoded_chunk) ) // chuck size is 128 bytes and the key is sent in bytes
this is called 4 times (which is wrong as u said)
What I do not understand is how can i send 512 bytes in 4 chunks How can I assemble the chunks? should I modify the simpleserial file itself?
Hi,
Youâll probably still run into the buffer limitations with 128 bytes, since the max buffer size is 200 bytes and ASCII encoding doubles everything. Iâd recommend using 64 byte chunks instead. If you change that, your code there should work. JP was just saying that the length of encoded_chunk
needs to match the length you expect in get_key()
, as thereâs a bit of data before and after encoded_chunk
is sent. Basically:
target.simpleserial_write('k', [0]*32); target.simpleserial_write('k', [0]*32)
is not the same as:
target.simpleserial_write('k', [0]*64);
As for what to do with that data, it should be pretty easy to handle this without modifying simpleserial at all. For example, you could use separate commands for each chunk ('k'
writes chunk 0, 'l'
writes chunk 1, etc.), or you could add an extra byte to encoded_chunk
that indicates to which chunk in your key buffer you should write to.
Hope that makes sense, let me know if you have any questions.
Alex
Hi Alex,
Thank you for the answer. I have two questions:
- my simpleserial function write ASCI encoded in bytes and in total i write 64 bytes in each chunk. Is it correct to pass bytes to the simpleserial_write ?
- the key I want to send is in total 100 kilobytes (I know it is huge! i took the example of 512 bytes just to test the chuning). So I guess using a command for each chunk will be dramatic?
I am really stuck.
Best,
Sou
Yup, thatâs right.
That is a very large key! You wonât be able to store that key on an STM32F3, as it doesnât have enough memory (only 12kB of RAM and 64kB of ROM). If you do get a target with enough memory, Iâd recommend using SimpleSerial V2, as it can send data many times faster than SimpleSerial V1 and can send more data per chunk (192 bytes should work for SSV2). Then you can use the scmd part of SSV2 as an index into your buffer. Or, if you donât need to swap the key out often, you can just put it in ROM, which you typically get more of than RAM, and upload it along with your code.
Alex
Would programming the FLASH memory be an option as it has 256KB?
Oh yeah, it does look like the F3 has 256kB of flash (looks like our linker script was for a different F3). Iâll get the linker script fixed up, but yeah you can definitely put that in flash instead.
In that case, you donât have to worry about transmitting the key over serial, as it will be uploaded along with the rest of the code when you program the device.
Alex
I am using an F303.
So does that mean I need to âhardcodeâ the secret key i.e., in the simpleserial-glitch.c I write
secret_key = âxyzâ;
Best
Iâd recommend explicitly marking the memory section you want to put the variable in and making it a global variable. Something like:
volatile uint8_t SECRET_KEY[KEY_LEN] __attribute__ ((__section__(".rodata"))) = {...};
should work. Iâd check the resulting listing and map file to make sure the memory allocation worked.
Alex
Adding the line above resulted in this error:
region `ROMâ overflowed by 183992 bytes
collect2: error: ld returned 1 exit status
When I define a smaller key, I receive this error:
/tmp/ccxXFIVa.s: Assembler messages:
/tmp/ccxXFIVa.s:159: Warning: setting incorrect section attributes for .rodata
Try grabbing the latest commit. Iâve updated the linker file with the correct memory sizes. That error message is at least a good sign that youâre putting the key in the right spot.
Alex
Thnx Alex,
That solved the issue, but the board is not responding anymore i.e., no matter what I sent through the simpleserial (even one digit) and try to send it back through the simpleserial. I get an empty answer.
ps: I commented out everything and the board still not sending back any response