AES 256 Bootloader - 14th round key (SCA201)

When trying to recover the 14th round key using the inverse_sbox_output (from cwa.leakage_models) this is what I get when running the attack with the Chipwhisperer Analyzer


The correlation is also completely off!

I 've tried to see if there was any jitter by plotting 5 traces as shown below:
But I wouldn’t say jitter is the problem.
(I use the Chipwhisperer Lite 2part with XMEGA as the target device)

Any suggestions on what to try on, would be more than welcomed, since I am really stuck!

–Update-- : The attack.point_range attribute was the problem, as soon as I removed the option and the attach run for all 15000 traces, it recovered the key correctly. However, it is clear that the decryption key(first half of it) that you provided is different than that of project.key(encryption key for AES-128), and this is also depicted in the table with our best guesses and the PGE which is referred to the previously used AES 128 encryption key. How can we update the Chipwhisperer analyzer to use/take in count the actual decryption key as the “correct one” (I’ ve already know that the ktp.next() method can return a different key as long as we set the _fixedKey attribute is set to False.) My own estimation is that the Bootloader uses a different (first half) decryption key, and just setting our leakage model to inverse_sbox_output obviously is not enough to just notify the Chipwhisperer analyzer about Bootloader’s correct key. So how do we notify the analyzer to do that and show in red characters the correct key (since you provided) with it’s corresponding PGE (obviously this is not a real life scenario since in the first place we don’t have any clue about bootloader’s key)?

–Update 2 --: After experimenting with the default jupyter_callback (from cwa module) I have built my own callback, like demonstrated in the orginal function in case someone wanted the correct key to be highlighted in green text.
code[key = [0xea, 0x79, 0x79, 0x20, 0xc8, 0x71, 0x44, 0x7d, 0x46, 0x62, 0x5f, 0x51, 0x85, 0xc1, 0x3b, 0xcb]
def format_stat(stat):
fmt=“{:02X}
{:.3f}”
if (type(stat) is int) or (type(stat) is float):
return str(stat)
return str(fmt.format(stat[0], stat[2]))
def color_corr_key(row):
global key
ret = [“”] * 16
for i,bnum in enumerate(row):
try:
if (type(bnum) is int) or (type(bnum) is float):
continue
if bnum[0] == key[i]:
ret[i] = “color: green”
else:
ret[i] = “”
except Exception as e:
print(“bnum: {}, key: {}”.format(bnum, key))
return ret
from IPython.display import clear_output
import numpy as np
import pandas as pd
def stats_callback():
results = attack.results
results.set_known_key(key)
stat_data = results.find_maximums()
df = pd.DataFrame(stat_data).transpose()
clear_output(wait=True)
display(df.head().style.format(format_stat).apply(color_corr_key,axis=1))]

Recovering the correct 32-bit key got me a little confused, since some things described in the Attacking the AES-256 Decryption/Encryption seem to me somewhat ambiguous.

At first Reading the “AES-256” chapter (from the Extending AES-128 Attacks to AES-256.ipynb) I understood that the rounds 14th and 13rd key rounds were referring to the decryption side. Back to the AES256 Bootloader attack.ipynb is clearly stated that “Perform a standard attack (as in AES-128 decryption) to determine the first 16 bytes of the key, corresponding to the 14th round encryption key”. The way a translate this is the following: Attacking the AES-256 as in AES-128 decryption(obviously using the inverse_sbox_output(Haming weight of the first decryption round ) as our leak model) will fetch us the first-half 16 byte of the decryption-key, which also is the 14th round encryption key. The it is said that “Using the known 14th round key, calculate the hypothetical outputs of each S-Box from the 13th round using the ciphertext processed by the 14th round, and determine the 16 bytes of the 13th round key manipulated by inverse MixColumns.”

So my question is is this 13th round key referring to the decryption round key or the encryption one?. It has to be the decryption one in as I understand it, since all the actions taken to recover the 13rd key are related to inverse calculations. Also which is the relation between the Encryption & Decryption Round Keys, I know that the same key is used in both encryption/decryption but it has to be some inversely proportional relation in their key schedule’s.

That’s the 13th round encryption (or 2nd round decryption key) that we’re getting.

Alex

1 Like

Thank you Alex, that is what I guessed my self after a lot of thought!