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!
Analyzing the results, I noticed interesting things:
- First and last four bytes (eight bytes in total) are clearly leaked by the HW(PT ^ KEY) model. They have high correlation and can be distinguished with very high probability as correct.
- Middle eight bytes don’t have strong correlation for the HW(PT ^ KEY) model. Some wrong subkey candidates win. At the same time there are leaks for sbox_output and shift_raw_output models.
- HW(PT ^ KEY) model leakage for first and last four bytes happens at the 1645 sample but the same leakage for middle eight bytes at the 807 sample.
- Middle eight bytes do leaks for sbox_output, shift_raw_output, AddRoundKey output models at the same point.
Looking at the whole trace I noticed two separate back-by-back AES patterns. This explains(maybe I wrong here in understanding) why I see AddRoundKey leakage at two different places.
The question is what is the reason of this design? Is it kind of countermeasure against the VCC glitch attack to prevent DFA targeted against the HW AES engine (compare two AES-engine outputs before sending result to outside)? It don’t looks like a pipeline, it is just two consecutive AES execution.
The next thing is I clearly see that sbox_output, shift_raw_output, AddRoundKey happen at the same sampled point.
Is it because of my sampling rate is too low and I don’t catch each state stored at registers or sbox_output, shift_raw_output, AddRoundKey are implemented as combinational logic?
The same picture for other correct keys. So it is not the artefact for this specific case.
Perhaps an AES mode that requires two passes?
This leaks happen on at least for key bytes 00 - 04. For 12-15 leaks are similar but have some small offset relative to 00-04.
This picture reveals that the same input plaintext is processed twice which is consistent with the full trace picture. This is why I suggested there are two AES processings which work with the same plaintext input. So it doesn’t look as two passed AES.
Looking at the driver code of PSOC62 I learnt that HW AES implemented as FIFO which processes a single input block of 16 bytes at once. So, the idea of possible pipeline interfering was dropped. Zooming in plots I figured out that the spikes are too narrow. I suggested that some leakage information is just missed using CW Lite. CW Husky confirmed this idea. 4x ADC sampling was changed on 12x sampling. The correlation spikes were a bit expanded and its magnitude got bigger.
Also I noticed that correlation for the correct subkey is strictly negative. So I filtered all positive correlations. With these changes it looks like the key can be completely recovered.
Here is the diagrams of the subkey which was totally noisy using CW Lite. But with CW Husky correlation looks much better. Green is the reference key. Missed keys are positively correlated candidates which were dropped. In red are all other candidates. Each picture is for its own leak model.
