ARIA Correlation Power Analysis

This post is not an introduction to the ARIA block cipher itself. I assume the reader already knows the ARIA round structure, substitution layers, diffusion layer, and key schedule.

The goal here is narrower: given power traces, known plaintexts, and known ciphertexts from an unprotected ARIA-128 implementation, recover two encryption round keys with Correlation Power Analysis (CPA), then combine them through the key schedule to recover the master key.

References:

• ARIA specification: RFC 5794

1. Attack Model

I assume the following setting.

1. The implementation uses a fixed 128-bit ARIA key.
2. The plaintext and ciphertext for each encryption trace are known.
3. The traces are roughly aligned.
4. The implementation is not masked or otherwise protected against first-order CPA.

For ARIA-128, recovering only the first encryption round key is not enough. The first round key ek1 is not the master key. ARIA derives encryption round keys from internal 128-bit words $W_0, W_1, W_2, W_3$, so I need enough round-key material to cancel the unknown schedule word and isolate $W_0$.

The attack flow is:

1. Use plaintext-side CPA to recover ek1.
2. Use ciphertext-side CPA to recover ek13.
3. Combine ek1 and ek13 using the ARIA-128 key schedule.
4. Test the remaining master-key candidates against known plaintext/ciphertext pairs.

For ARIA-128, $W_0$ is the left half of the cipher key material. Because the key is exactly 128 bits, $W_0$ is the master key.

2. Trace Parsing and Alignment

The trace file starts with a small header. The first 32-bit value is the trace length.

The next 32-bit value is the number of traces. In this dataset the trace length is 24000, and the trace count is 5000.

The sample values are stored as float32. The parser reads the header first, then reads TraceLength * TraceNum floating-point samples.

Plotting a single trace gives a quick SPA sanity check. The repeated activity is visible, and there are 12 major round-like regions. That matches ARIA-128, which has 12 rounds. ARIA-192 and ARIA-256 would have 14 and 16 rounds.

Before running CPA, I also overlay several traces in the same window. Point-wise correlation assumes that the same operation occurs at the same sample index across traces. If the traces are misaligned, the correct key guess can lose its peak.

The traces are aligned well enough for a first CPA pass.

3. First-Round CPA Target

ARIA uses two substitution-layer types. For the first round of encryption, the relevant pattern is type 1:

The first useful CPA target is the substitution output after XORing the plaintext state with ek1.

For byte position $b$, trace $i$, and key-byte guess $k$, the intermediate value is:

where $S_b$ is selected by the ARIA byte position:

Then I use a Hamming-weight leakage model:

The ARIA implementation already has the four byte S-box tables, so the CPA code can index them directly.

The core leakage model is the same shape as the AES CPA attack:

1
for (int byte_pos = 0; byte_pos < 16; byte_pos++) {
2
    for (int key = 0; key < 256; key++) {
3
        for (int trace_idx = 0; trace_idx < trace_count; trace_idx++) {
4
            uint8_t iv = S[byte_pos % 4][PT[trace_idx][byte_pos] ^ key];
5
            predicted_hw[trace_idx] = hamming_weight(iv);
6
        }
7

8
        correlate_against_trace_window(byte_pos, key, predicted_hw, traces);
9
    }
10
}

For each byte position, the correct key guess has the strongest absolute Pearson correlation peak:

The recovered first round key is:

ek1 = CB F6 D7 4C 0B 78 B9 30 22 B4 7E AA 06 E7 01 2A

The correlation trace also lands in the expected early-round region.

At this point the CPA itself is working, but ek1 is only a round key. Recovering the ARIA-128 master key requires one more round key.

4. Key-Schedule Relation

ARIA key expansion has two stages:

1. Generate the internal 128-bit words $W_0, W_1, W_2, W_3$.
2. Generate encryption and decryption round keys from those words with XOR and cyclic rotations.

For ARIA-128:

and $KL$ is the 128-bit master key.

The round keys that use $W_0$ and $W_1$ are especially useful here. Using the rotation convention from the implementation:

Equivalently, $\operatorname{rotr}_{128}(W_1, 97)$ is $\operatorname{rotl}_{128}(W_1, 31)$.

If I rotate ek1 left by 50 bits, the $W_1$ term lines up with the $W_1$ term in ek13:

XORing that with ek13 cancels $W_1$:

So after recovering ek13, the problem becomes solving:

for $W_0$.

The implementation uses a byte rotation helper for the ARIA key schedule.

5. Ciphertext-Side CPA for ek13

ARIA-128 uses 13 encryption round keys. The final whitening key is ek13, so the ciphertext gives another CPA entry point.

The final substitution-layer direction is not identical to the first-round direction. In the encryption direction, the last substitution layer uses the other S-box ordering. However, when I work backward from the ciphertext, I first XOR a key guess and then apply the inverse substitution. Because ARIA pairs the S-boxes as inverses:

the same table order used for the ek1 CPA can be reused in the ciphertext-side model. The input changes from plaintext bytes to ciphertext bytes:

The recovered final round key is:

ek13 = 9F 6B DD 65 DB 73 71 3B F8 CF 67 77 D9 D1 95 9F

For this pass, I used fewer traces and a narrower window to speed up the run, so the result is noisier than the ek1 CPA. The peak is still strong enough to recover all 16 bytes.

6. Recovering the Master Key

Now both round keys are known:

ek1  = CB F6 D7 4C 0B 78 B9 30 22 B4 7E AA 06 E7 01 2A
ek13 = 9F 6B DD 65 DB 73 71 3B F8 CF 67 77 D9 D1 95 9F

The key-schedule relation gives:

T = rotl128(ek1, 50) ^ ek13
  = 7B AB 57 B4 21 DB 6A A7 FC 64 48 AC 84 E1 B8 7D

and:

This equation does not uniquely determine $W_0$ without a small brute force. Since:

the bit relation splits into two independent cycles: one for even bit positions and one for odd bit positions. Therefore, two seed bits are enough to enumerate every possible $W_0$ that satisfies the equation.

The bit-walk in the implementation looks like this:

1
for (int seed_odd = 0; seed_odd <= 1; seed_odd++) {
2
    for (int seed_even = 0; seed_even <= 1; seed_even++) {
3
        memset(key_bits, -1, sizeof(key_bits));
4

5
        key_bits[127] = seed_odd;
6
        walk_cycle(127, key_bits, T_bits);
7

8
        key_bits[126] = seed_even;
9
        walk_cycle(126, key_bits, T_bits);
10

11
        print_candidate(key_bits);
12
    }
13
}
14

15
void walk_cycle(int idx, int *key_bits, const int *T_bits) {
16
    int start = idx;
17

18
    do {
19
        int next = (idx + 128 - 50) % 128;
20
        key_bits[next] = key_bits[idx] ^ T_bits[idx];
21
        idx = next;
22
    } while (idx != start);
23
}

That produces four candidates:

12 27 66 34 21 1F 1A 63 0C 60 00 31 1C 31 3C 01
47 72 33 61 74 4A 4F 36 59 35 55 64 49 64 69 54
B8 8D CC 9E 8B B5 B0 C9 A6 CA AA 9B B6 9B 96 AB
ED D8 99 CB DE E0 E5 9C F3 9F FF CE E3 CE C3 FE

Only one candidate encrypts the known plaintexts to the known ciphertexts:

Master key = 47 72 33 61 74 4A 4F 36 59 35 55 64 49 64 69 54

The plaintext and ciphertext files provide the final check.

7. What Matters in This Attack

The CPA part is conceptually the same as the AES attack: choose a byte-wise nonlinear intermediate value, predict its Hamming weight for every key guess, and correlate that prediction against the measured traces.

The ARIA-specific part is what happens after recovering round keys. ek1 is not the master key, and stopping there would be a key-schedule mistake. The useful observation is that ek1 and ek13 share the same $W_0$ and rotated $W_1$ structure:

After aligning the rotations, $W_1$ cancels and leaves a small two-bit ambiguity in $W_0$. Known plaintext/ciphertext pairs remove that ambiguity immediately.

So the attack succeeds in two layers:

1. Side-channel analysis recovers enough round-key material.
2. Cryptanalytic use of the key schedule turns that round-key material into the master key.