CWLITEARM NO ACK from Target

Hello everyone,

I recently purchased the ChipWhisperer Nano development kit to evaluate the side-channel attack (SCA) performance of the newly developed Ladybug AEAD algorithm. I have been following the documentation available on the official ChipWhisperer GitHub to familiarize myself with the platform and the provided AES tests.

Current Setup:

  1. Target Board: CWLITEARM/STM32F3.
  2. Capture Board: ChipWhisperer Nano.
  3. Firmware Changes:
  • I added the Ladybug AEAD implementation to chipwhisperer/firmware/mcu in a new simpleserial-ladybug folder.
  • Updated the makefile to include Ladybug AEAD as a new target.

Progress So Far:

  • Successfully compiled the Ladybug AEAD firmware and generated the .hex file.
  • Uploaded the firmware to the STM32F3 target using the programmer:

vbnet

Copy code

Detected known STM32: STM32F302xB(C)/303xB(C)
Extended erase (0x44), this can take ten seconds or more
Attempting to program 16547 bytes at 0x8000000
STM32F Programming flash...
STM32F Reading flash...
Verified flash OK, 16547 bytes

Issue:

When I attempt to capture power traces using my Python script (adapted from the provided AES examples), I encounter an issue with the target acknowledgment (ACK). While I can see the key being set successfully, the target does not always respond correctly during the capture loop. Here is a summary of the log:

vbnet

Copy code

Initializing target communication...
(ChipWhisperer Target WARNING|File SimpleSerial.py:447) Unexpected start to command: 
Target version: None
Setting key: 2b7e151628aed2a6abf7158809cf4f3c
(ChipWhisperer Target ERROR|File SimpleSerial.py:351) Target did not ack
Attempt 1/3 failed: Device failed to ack
Target reset and buffer flushed.
Setting key: 2b7e151628aed2a6abf7158809cf4f3c
Key set successfully.
Starting capture loop...

How I Set Up My Main Function:

This is how I implemented the main function on the target device to handle communication with the ChipWhisperer:

c

Copy code

int main() {
    // Initialize the platform, UART, and SimpleSerial
    platform_init();          // Initialize the platform
    init_uart();              // Initialize UART for communication
    trigger_setup();          // Initialize trigger pin
    simpleserial_init();      // Initialize SimpleSerial protocol

    // Register SimpleSerial commands
    simpleserial_addcmd('k', 16, set_key); // Key Set command
    simpleserial_addcmd('p', 16, simpleserial_encrypt); // Encrypt command
    simpleserial_addcmd('c', 16, simpleserial_decrypt); // Decrypt command

    printf("Commands registered successfully.\n");

    // Loop indefinitely to process commands
    while (1) {
        simpleserial_get();
    }

    return 0;
}

Troubleshooting Steps I’ve Tried:

  1. Synchronization: I added a dummy synchronization step in the main function by sending a version message (‘v’) at startup:

c

Copy code

simpleserial_put('v', 0, NULL); // Indicate readiness

However, the Python script still shows Target version: None.
2. Buffer Flushing: I ensured the target buffer is flushed and reset between commands:

python

Copy code

scope.io.target_pwr = "low"
time.sleep(0.5)
scope.io.target_pwr = "high"
time.sleep(1)
target.flush()
  1. Retries: Added retry logic for setting the key and capturing traces.
  2. UART Configuration: Verified that the UART settings on the target match those in the Python script.

Request for Help:

  • Has anyone successfully integrated a custom AEAD algorithm with ChipWhisperer?
  • What might I be missing in the target or Python script setup to resolve the “did not ACK” issue?
  • Are there any specific debugging techniques or tools to identify the root cause of target communication failures?

Any guidance or suggestions would be greatly appreciated!

Thanks in advance!

  1. ‘v’ is a reserved SimpleSerial command, but it needs to be implemented in the target firmware in order to exist. Your main() doesn’t implement it, so don’t send your target a ‘v’ command.
  2. What you call “buffer flushing” is simply resetting the target, which should not be required with proper functioning firmware; besides, resetting the target before each command would be very impractical.

Any algorithm can be implemented on ChipWhisperer targets, provided that the target has sufficient memory for it. I would use a debugger to see what your target is doing when it doesn’t respond as you expect it to. Is it stuck somewhere? Did it crash?