"Lord Feistel" Puts an Oscilloscope to Work Demonstrating Why Rolling Your Own Crypto Is a Bad Idea

Pseudonymous maker "Lord Feistel," hereafter simply "Feistel," has demonstrated just how much of a bad idea it is to roll your own cryptography implementation — building a proof of concept to show how a power analysis side-channel attack can leak keys from a microcontroller.

"Recently, I observed people implementing cryptography for Arduino by themselves," Feistel explains. "Several of them can be found over the internet, some by the way are in well-known libraries. I decide to do this small PoC (Proof of Concept) to show why [it] is important not [to have] invented your own cryptography algorithm, but also [to] use a robust implementation of such algorithms."

Feistel's project builds on existing work on differential and simple power analysis (DPA and SPA), attacks, which revolve around a processor requiring more power to do some things than others. In this case, those things are the math surrounding RSA public-key cryptography — a highly secure cryptographic system that, nevertheless, can fall if not properly implemented.

Using an off-the-shelf Rigol DS1102 digital storage oscilloscope (DSO) and a bench-top power supply, Feistel wired a shunt resistor circuit up to measure the current drawn by a Microchip ATmega328P microcontroller. As the current increases, the voltage drops — visible on the oscilloscope's screen. When the processor is working harder, it's drawing more current — and, as with artificially-induced drops, that too is visible on the oscilloscope.

To demonstrate the real-world potential of the attack, Feistel used a known-vulnerable fast exponentiation function as used in several microcontroller-focused RSA implementations — working with a "key" of alternating zeroes and ones, for ease of demonstration. "Using the hardware previous mentioned it is possible to see the spectrum of power consumption in the oscilloscope," the maker explains. "The periods which the voltage drops for a long time it means the bit 1 of the key is being processed, otherwise is the bit 0."

The conclusion: don't be tempted to roll your own, or to rely on an unproven implementation even if it's shared widely on social coding platforms. "Even minor implementation flaws or oversights can inadvertently leak information about the private key," Feistel notes, "compromising the entire security of the system."

The full write-up is available on GitHub, along with an introduction to number theory and the source code under the reciprocal GNU General Public License 3.