I’m trying to attack the MbedTLS AES-256 decryption function on CW-LITE. I understood that Tutorial A8 32bit AES - ChipWhisperer Wiki mentioned the SubBytes output is still buried in the 32-bit T-table implementation. Also, I successfully recovered all round keys in the encryption function. However, in the decryption, I can only recover the 14th RK, while the 13th RK was always some random. I understood that the mixcolumn required addtional shiftrow() and mixcolums() on the recovered key to get the real 13th key, but the Pearson correlation for each guessed key was alwayse below 0.4. I inferred it should be some problem where I hypothesis the internal state incorrectly. What I hypothesis for the 13th round is that the input is the output of the 14th round’s Subytes, and the output is the state after the next Subytes operation. Could you please tell me whether my approach is correct? If not, what should be the correct approach and would it be possible for me to access some reference code?
BTW, I tried to verify this decryption attack using the archive-PA-Multi_1-Breaking_AES-256_Bootloader.ipynb. A pure running of the code can successfully find the 14th and 13th RK. However, after I program the mbedtls AES-256 code into the device and run the notebook again, it cannot find the 14th key even! I’ve checked the AES code works correctly. Do you have any idea why this is happening and how to fix it?
Are you using the CW-Lite ARM chip? If so, there’s a line in the code you posted that restricts the attack to a smaller portion of the overall power trace. Try removing that.
Have you tried capturing more traces? The standard leakage model works alright for T-Tables implementations, but there’s actually a more accurate one you can use. 200 is probably a bit too low for something like this. Try doing 2000 or so to see if you can recover some bytes of the key.
This attack actually recovers inv_mixcolumns(inv_shiftrows(k13)) instead of k13, so make sure you’re aware of that when you’re checking if you’ve recovered the correct key.
Hi Alex,
Thanks a lot for your reply!
1 and 2: Yes, the ARM chip. After I remove it, the inverse_sbox_output model still does not work for 200 traces. Then I tried the t_table_dec model and it worked well to capture the RK14 correctly with 200 traces, but still incorrectly for RK13. I also tried 2000 traces, but it did not work for RK13. Since I get Pearson correlations always below 0.4, I think the leakage model should be incorrect.
#T_f796a_row4_col8 {
color: red;
}
Finished traces 2175 to 2200
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
PGE=
191
22
90
67
72
151
41
159
3
166
251
70
58
170
6
67
0
77 0.223
5A 0.196
D0 0.214
68 0.245
7A 0.258
E9 0.189
67 0.213
B2 0.235
B2 0.224
ED 0.197
8E 0.191
FB 0.224
D5 0.142
64 0.192
D7 0.208
33 0.190
1
13 0.221
5B 0.186
21 0.205
69 0.232
7B 0.219
8E 0.178
66 0.210
DF 0.205
B3 0.203
C2 0.192
EA 0.183
86 0.216
80 0.137
A6 0.172
CC 0.189
EA 0.186
2
12 0.217
3F 0.183
4C 0.185
0C 0.192
54 0.196
E1 0.175
03 0.191
D6 0.198
9C 0.175
6E 0.167
86 0.167
E2 0.203
77 0.136
BD 0.169
40 0.182
8E 0.174
3
10 0.216
37 0.176
4D 0.184
04 0.189
55 0.169
1F 0.162
49 0.182
B1 0.188
AB 0.174
AE 0.166
7B 0.153
8E 0.201
3D 0.133
C3 0.156
68 0.180
A0 0.164
4
CE 0.172
D3 0.174
77 0.173
0D 0.165
DC 0.160
8D 0.155
0B 0.175
B3 0.186
97 0.173
C1 0.165
F3 0.152
8F 0.197
3C 0.129
19 0.154
C3 0.178
28 0.164
I’m a lit bit confused that how should I modified the AES256_Round13_Model. Suppose until the RK13 SubBytes, we have AddRK14, INV-ShiftRow, INV-SubBytes, AddRK13, INV-MixColumn, INV-ShiftRow and INV-SubBytes. Which value should I put as the return value for AES256_Round13_Model.leakage? I’ve replaced the RK14 there.
3. Thanks for your remind. I’m aware of that. But because I cannot get a Pearson correlation higher than 0.4, I inferred that the problem should happen in the leakage models.
I think you can use the t_table for the 13th round as well by grabbing t_table_hw_dec from software/chipwhisperer/common/utils/aes_tables.py and returning t_table_hw_dec[self.inv_sbox(result[bnum] ^ guess[bnum])]. Try giving that a try.
