Difference between revisions of "AES-CCM Attack"

1-B: Finding interesting areas

Doing this requires switching the attack algorithm to the AddRoundKey output (where AddRoundKey is just an XOR operation):

Note running it against all points might give you a memory error (especially on a 32-bit system). We don't need all bytes though, so to avoid this just change these settings:

• Only enable a single subkey (i.e., say byte 0).
• Set reporting interval & traces per attack to same value (say 100 I used here).

The result will show you correlation where the input data was used (possibly XORd with any constant). You'll get something like the top graph, where I've added an overlay of the power trace below it:

Note this is basically showing us where the AES-CTR output occurs, then where the AES-CBC input happens. The correlations correspond to the following I think (there may be a mixup of where the load occurs - if any of those intermediate states are loaded/saved it would show up):

• Load of CT data.
• XOR of AES-CTR output 'pad' with input CT.
• XOR of previous with the old AES-CBC state as part of AES-CBC input processing.
• AddRoundKey of previous during AES-ECB block.

1-C: Modified First-Round Key

The first step is to perform a standard CPA attack. The only issue is we won't recover the actual encryption key used , instead we recover , since we basically roll all the constant inputs into what we call a `modified key'.

So let's do a first-round attack focused around points (180000,22000) to start (roughly picked from the power traces). To do this:

• Turn back on all bytes (if previously disabled).
• Switch leakage model to S-Box output.

You'll likely find after a number of traces you could plot correlation for bytes 0 & 15, and get a better idea where the attack should happen. Looking at the following I can see we could focus on points (18600,19200) and might get a more reliable attack.

Finally, you should get this `modified key', in this example we can see it appears to be 94 28 5D 4D 6D CF EC 08 D8 AC DD F6 BE 25 A4 99:

The next step is to use this to recover the complete round-key.

1-D: True Second-Round Key

In what might seem like magic, we can use this modified key to directly determine the second-round key (the true key). This was originally presented by J. Jaffe in A First-Order DPA Attack Against AES in Counter Mode with Unknown Initial Counter. The reason this works is if you remember we recovered . In the AES algorithm the first thing we do is the AddRoundKey, which is:

.

In the true algorithm we have the case of:

And when we use our modified key, we are feeding the CT directly into AddRoundKey:

Where the basically includes those additional constants, instead of them being added as part of the ciphertext. Ultimately it means the output of AddRoundKey, and thus processing of later rounds, is identical in both cases. So we can perform a CPA attack on the 2nd-round key, and directly recover the "true" first-round key by rolling back the key schedule.

This requires a custom leakage model, which we can make fairly easily:

from chipwhisperer.analyzer.attacks.models.AES128_8bit import AESLeakageHelper

class Round2(AESLeakageHelper):
    name = 'HW: Round-2 Key'
    def leakage(self, pt, ct, key, bnum):
        r1key = [0x94, 0x28, 0x5D, 0x4D, 0x6D, 0xCF, 0xEC, 0x08, 0xD8, 0xAC, 0xDD, 0xF6, 0xBE, 0x25, 0xA4, 0x99]
        state = [pt[i] ^ r1key[i] for i in range(0, 16)]
        state = self.subbytes(state)
        state = self.shiftrows(state)
        state = self.mixcolumns(state)
        return self.sbox(state[bnum] ^ key[bnum])

And we insert it into the system by modifying the analysis script in initAnalysis():

leakage_object = chipwhisperer.analyzer.attacks.models.AES128_8bit.AES128_8bit(Round2)

You can perform the same CPA attack, modified to occur around the second round. In this example I found points (20520, 21950) worked well - but you can try a much larger point-range, and then scale that down to get a faster calculation. This gives us the round-2 key, in this example appears to be AA 61 B3 E3 C7 AE 5F EB 1F 02 82 1D A1 27 26 84:

Using the key-schedule widget, you can then determine the true initial key was 94285d4d6dcfec08d8acddf6be25a499 (which matches what was programmed in this example):

Note in addition you can perform the operation to recover . If we knew either one of those we could then completely break AES-CCM, since we would know the AES-CBC I.V., along with the AES-CTR nonce/format.

For a well-known implementation (say in IEEE 802.15.4) we are done, as the nonce format is known. You can perform an encryption with the known nonce to recover , then immediately recover . Note this isn't the true I.V. as written in the file, but the result of the AES-CBC state up until the first encryption block was performed. Thus you cannot change the authentication-only blocks without doing further work to reverse back to the original I.V.

In the event the AES-CTR nonce input is unknown, additional work is required (detailed below).