AES key recovery doesn't work for the PSOC62 target board

Hi.

I recently got another one target board to evaluate which is PSOC62 based target board (CW308T-PSoC62 - NewAE Hardware Product Documentation).
This board has pretty interesting MCU.
I didn’t find any information in the Newae resources regarding countermeasures to protect AES for the PSOC62 MCU.
At the first glance, there are no random delays but the AES-128 key cannot be recovered using the “lastround_HD_gen”, “sboxInOut_HD_gen”, “sbox_HW_gen” leakage models.

The complete picture of AES-128 pass looks:


This picture clearly reveals AES location in the power traces.

Zoomed in picture looks:

Using the “lastround_HD_gen” attack, we can take safely take the range [2000 … 2500] but for the “sbox_HW_gen”, “sboxInOut_HD_gen” the range [1500 … 2000].

More zoomed in picture which looks perfect in my opinion:

As a result I get only junk bytes for the key regardless of having perfect power traces:

Does PSOC62 use masking to protect HW AES? Did someone break HW AES-128 on this MCU?

@coflynn Probably, you are a right person to ask this question…
I guess you originally developed this target board. Was this board developed with the intentions to get the HW AES implementation protected by masking?
Or PSoC62 has no masking protection?

Hi @NewDwarf, thanks to share your interesting experiments. Would you please provide the source of the firmware you used for this analysis. It would help a lot for comparing your result with mine.

I am not the OP and I have no specific experience with this target, but the datasheet does not suggest any side-channel attack protections.

I also don’t know whether the OP used the target’s HW AES capabilities here.

Finally, figured out the suitable leakage model. It is Sbox input. I am not sure why but using standard CW API didn’t revealed leak.

I just created a set of custom leak models and this one works for PSOC62 target

def model_hwf1(plaintext, key_guess, target_byte):
    """HWF1: HW(PT ⊕ KEY)"""
    return bin(plaintext[target_byte] ^ key_guess).count('1')

Here is the consolidated result for all different models with using the correct key 0x15

Same, but for wrong key candidate

So, HW(PT ⊕ KEY) leakage model is a solution for this target!