I see a lot of research in very sophisticated side-channel attacks on crypto sys
ID: 650337 • Letter: I
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)?
Explanation / Answer
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."