Scope.adc.samples & communication speed (Husky)

Embedded Security ChipWhisperer Hardware
1

I faced with the problem when the scope.adc.samples value affects the Husky’s UART speed.

For example, if the “samples” value 2000, UART speed is ~50 it/sec. When I increase the “samples” value up to 13000, UART speed is also increased up to 110 it/sec.

I didn’t learn the FPGA and Husky’s MCU sources yet but I guess it makes sense to ask developers why this happens and whether I can adjust some parameters to get high speed using the relatively small “samples” value.

2

I think that when you say “UART speed”, you mean the speed at which you are able to collect power traces?

In general, increasing scope.adc.samples will slow down the capture rate, here you are seeing the opposite- this is likely due to how the USB stack decides to handle the different transfer sizes.

If you are interested in really speeding up your captures, read the following:

3

Yes, it was incorrect statement. I would use “communication speed“

4

Nice feature! Never used it before.

5

@jpthibault Regarding fast capturing

scope.adc.samples = 50
scope.adc.segments = 1000

target.simpleserial_write('k', bytearray(16))
target.simpleserial_wait_ack()
target.simpleserial_write('n', list(int.to_bytes(scope.adc.segments, length=2, byteorder='big')))
target.simpleserial_wait_ack()

scope.arm()
starttime = datetime.datetime.now()
target.simpleserial_write('f', bytearray(16))
#target.flush()
ret = scope.capture(poll_done=True)
wave = scope.get_last_trace()
resp = target.simpleserial_read('r', 16)
elapsed = datetime.datetime.now() - starttime
print('Elapsed time: %1.3f seconds; %5.1f captures/second' % (elapsed.total_seconds(), scope.adc.segments/elapsed.total_seconds()))

Looking at the above set of commands, the “n“ command is absent in the simple serial v1 protocol. I think the ‘s‘ command should be used instead:

    #if SS_VER == SS_VER_2_1
    simpleserial_addcmd(0x01, 16, aes);
    #else
    simpleserial_addcmd('k', 16, get_key);
    //simpleserial_addcmd('k', 32, get_key);
    simpleserial_addcmd('p', 16,  get_pt);
    simpleserial_addcmd('x',  0,   reset);
    simpleserial_addcmd_flags('m', 18, get_mask, CMD_FLAG_LEN);
    simpleserial_addcmd('s', 2, enc_multi_setnum);
    simpleserial_addcmd('f', 16, enc_multi_getpt);
    #endif

Also, I think this approach will work for the known key only assuming implementation of the “f“ handler:

uint8_t enc_multi_getpt(uint8_t* pt, uint8_t len)
{
    aes_indep_enc_pretrigger(pt);

    for(unsigned int i = 0; i < num_encryption_rounds; i++){
        trigger_high();
        aes_indep_enc(pt);
        trigger_low();
    }

    aes_indep_enc_posttrigger(pt);
    simpleserial_put('r', 16, pt);
    return 0;
}

I can recover the whole plaintext bunch from the single received ciphertext( in the case if the key is known). But if the key is unknown, it will be impossible to do it.

6

As our documentation states: “This is where you may have to get creative; the solution will depend on the target operation and the objective of your attack.”

There is no one-size-fits-all solution here; the intent of our example is to show what’s possible. The rest is up to you.

7

Improved the speed from 50 it/sec till 160 it/s using the batch mode. Pretty fast. Thanks for the hint.