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

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)?

-
This is an interesting question but I'm not sure it has a correct answer. Sounds like a great topic for a discussion thread. –  machine yearning Sep 12 '12 at 2:19
@FrancisW.Usher, that was definitely something I had thought about. I think it can be answered if someone knows the industry well enough. If most of the vendors out there are worried about this stuff and putting protections in their products, then there is good reason to believe that the attacks are possible (as the protections only add to cost, etc). We'll see, right. –  mikeazo Sep 12 '12 at 11:26

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:

• 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.
• 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.
• 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}$.
• 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).
• Micro-probing to spy on bus lanes, leaking all kind of secret information.
• Simple Power Analysis directly leaking bits of exponent in RSA.
• 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).
• Differential Power Analysis, allowing key recovery.
• 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, part2, part3; and this recent 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.

-
Uhm. You link two articles that advocate for more widespread measures against side channel attacks. However, both are authored by a company (now acquired) that sells such measures via patent licensing. Such company is (or was) definitely a serious and respectable one, but to me it does not look like a totally objective point of view. –  SquareRootOfTwentyThree Sep 25 '12 at 19:49
@SquareRootOfTwentyThree: indeed, authors of the articles I quote are preaching for their solutions. It remains their arguments are technically valid and convincing. I have no such conflict of interest, and can tell you from observing my industry that the threat of failing a certification lab test on DPA and loosing a business opportunity is real. I won't tell you DPA is among the techniques causing the most harm from real adversaries; I believe other forms of channel leakage are, second only to exploitation of plain carelessness. –  fgrieu Sep 26 '12 at 7:05

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.

-
"Any class of attacks becomes a practical concern the moment it starts to become attractive for an attacker with respect to other classes": This is fine in theory, or in a rational world; but in our world, attacks that are not economically sound for an attacker often still make a lot of harm to the vendor of the vulnerable system. –  fgrieu Sep 12 '12 at 13:18
@fgrieu I have not used the word "econonomically" but only "rewards". Academic attacks, script kiddies, terrorists and so on don't go after money but they can still be modeled while doing risk analysis. Implementation of countermeasures is expensive, so I don't think they should be implemented "just in case". –  SquareRootOfTwentyThree Sep 12 '12 at 15:21
I wanted to emphasize that risk analysis, or whatever the decision tool is named, often should take into account the risk of bad publicity due to an attack, and risk of lost sales due to having no clear technical safeguard against some hypothetical attack. This gives very good reasons to include countermeasures to side-channel attacks even in the absence of justification in term of benefit to an identifiable adversary. –  fgrieu Sep 12 '12 at 16:55
I agree the risk should be assessed (with the threat agent possibly being a market competitor) but that does not automatically imply that you will find a good motivation to address side-channel attacks. It's very hard to receive bad publicity out of a breach due to side channels attacks (which are today perceived as sophisticated attacks since they require some knowledge of statistics in most cases) unless the product is very widespread and there is a real brand to defend. –  SquareRootOfTwentyThree Sep 12 '12 at 19:37

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."

-