[marcan_42]

The security of cryptographic primitives relies on the mixing that happens from the first round to the last round. If you can analyze the input-output relationship of a single round, you can easily derive the round key (and the way the AES key schedule works, if you have any round key you can run it backwards to derive the original key). Bit flips in the middle of the algorithm allow you to do just that; if you have a bit flip in the second to last round, that'll have a specific effect on the output, and that effect will depend on a small part of the round key. Collect enough samples and you can solve for it. It turns the problem of brute forcing a 128 bit key into the problem of brute forcing a few bits at a time, because with only a round or two there is very little diffusion, i.e. every output bit only depends on a few key bits.

I've done the same thing to break "white-box" AES implementations, which are software versions of AES with the algorithm obfuscated and the key baked into it, in the form of flattened per-round-byte lookup tables (this concept is complete snake oil, but a few companies insist on selling it; they claim it's hard or impossible to get the key out, but this method works every time). You can introduce faults by patching the code or using a debugger to change state in the last round or two, and compute the key from the results. I did a targeted attack where I surgically introduced faults by replacing intermediate values with ones from a different input (which works even when the algorithm uses redundant, booby trapped encodings, which is another feature these vendors peddle), but in most cases you can also just literally randomly corrupt execution and use the same script Yifanlu wrote, just like a random hardware glitching attack.