Sending a long key with simpleserial

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?

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:

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, for example, and how our AES attack notebooks communicate with this target.

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?


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.


Hi Alex,
Thank you for the answer. I have two questions:

  1. 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 ?
  2. 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.

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.


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.


1 Like

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”;


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.


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.


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