How practical are side-channel attacks and how much of a concern are they?

Question

I see a lot of research in very sophisticated side-channel attacks on crypto systems. Most (but definitely not all) seem to follow a trend, namely, the crypto system does something very dumb like decrypt any block given to it with no IV or nonce (so usually ECB mode).

That said, there have been practical attacks against smart cards and timing attacks against RSA.

So, when building a system which uses cryptography (be it public or symmetric key), how practical of a concern are such attacks? And, what guidelines can be followed to determine if your systems needs protections (be they power analysis protections, emissions, timing, etc)?

Answer 1

Yes, side-channel attacks are practical and a real concern, if the past is indicative of the future.

I've been professionally involved with Smart Cards since the mid eighties, and have repeatedly witnessed deployed systems vulnerable to many forms of side-channel attacks; examples (I personally did 1 and 3):

1. RAM buffer not cleared at reset, readable (with standard command Get Response), leaking state of previous PIN comparison, even if incrementing the PIN presentation counter had been inhibited (by hardware reset or/and removing EPROM programming voltage); that allowed recovering the 4-digit pins with expected 5000 attempts.
2. Timing dependency where the duration of PIN presentation with permanent-memory writes inhibited leaks if the PIN is correct or not, to the same effect.
3. Timing dependency where the duration of a comparison between values leaks the index of the first incorrect byte, allowing finding an $n$-byte value with expected $n\cdot2^7$ attempts instead of $2^{8\cdot n-1}$.
4. Return to manufacturer test mode (by a software exploit, hardware modification or upset), allowing extraction of permanent memory content, including secrets (variant: normal software can be coerced to read the wrong location).
5. Micro-probing to spy on bus lanes, leaking all kind of secret information.
6. Simple Power Analysis directly leaking bits of exponent in RSA.
7. Simple Power Analysis leaking activity (e.g. start programming of permanent memory), which combined with timing measurement leaks sensitive information (e.g. good or bad PIN, before that is recorded).
8. Differential Power Analysis, allowing key recovery.
9. Fault Injections (often considered side-channel attacks).

I have seen this causing great embarrassment to the suppliers of the vulnerable Smart Cards, and believe multiple reports that in the (distant) past, such vulnerabilities occasionally have been exploited on a large scale, especially in the field of Pay-TV with Smart Card.

More generally, when a device using cryptography is broken, this is often by means better described as a side channel attack than a cryptographic attack.

Addition: check this introductory article's part1 (alt.), part2 (alt.), part3; and this 2012 paper showing remote SPA and DPA attacks on Smart Phones and PDA.

---

If a cryptographic device/system can get in the hands of the adversary or otherwise become accessible enough (timing/Tempest/DEMA/SPA/DPA attacks can be remote to some degree), and it contains any information which confidentiality or even integrity matters (such as secret/private keys, authenticators, counters..), then one needs to pay close attention to side-channel attacks.

Answer 2

So, when building a system which uses cryptography (be it public or symmetric key), how practical of a concern are such attacks?

Any class of attacks becomes a practical concern the moment it starts to become attractive for an attacker with respect to other classes, and provided any successful attack brings rewards that outbalance the cost. That is true also for side-channel attacks; if your system can be compromised much more easily by other simpler means (e.g. social engineering, software bugs, test modes, you name it), spending money or time on adding protection against side-channel attacks may not make much sense. Same thing if the attack takes 1 year to mount and all you get is the ability to post on someone's Facebook wall.

And, what guidelines can be followed to determine if your systems needs protections (be they power analysis protections, emissions, timing, etc)?

A risk analysis is the first tool to guide you in identifying which attacks vectors are relevant (e.g. which system properties leak information to an attacker). For instance, if you trust the physical environment and its surrounding and your system is connected to external networks, you can ignore electromagnetic radiations, but not timing, padding oracle attacks, cache attacks and so on.

After that, you can implement some countermeasures where possible.

Answer 3

I'm not sure what you mean by a "practical" concern. There are firms offering DPA testing services of PIN pads, so I'd say that yes, defending against DPA is a pragmatic decision. Researchers demonstrated OpenSSL timing attacks that were very successful against other servers located in the same physical Amazon cloud server.

Most successful crypto attacks I know of have been "side-channel" attacks. Protocols are generally the weak links, much more so than the well-tested algorithms. (The same is not true for hash digest algorithms, however, as most have had flaws discovered recently.) In particular, I've seen many problems arise because designers have added support for forward and/or backward compatibility in the same implementation. Or they may have a code defining the choice of protocol between AES-256, IDEA, CAST, or 3DES, but if you set the protocol to something invalid, the encryption is downgraded to the old default value of DES, ROT-13, or no encryption at all.

I would recommend that once you come up with your protocol, have it reviewed by external parties who are motivated (paid) to have you get it right. You need cryptographers who are fluent in current attack scenarios. As you throw trained eyeballs at your protocol, explain to them the flaws you were aware of and how you mitigated them, then let them work on the problem. Once you get their feedback, listen to it with an open mind. The worst decision you can make is to say "I know what I'm doing."