Thomas Ptacek made a few security predictions about 2006. I am not qualified to make such predictions, but hindsight lets me comment on one of his predictions.
5. Side-Channel and Timing Attacks Go Mainstream
The prediction I am least qualified to make, but most interested in. Remote cache timing, local cache timing, HTT, virtualization, distributed side-channel analysis. To paraphrase a friend who knows the space better than me: “The 10 people in the world who actually spent any time thinking about this had no access to a [useful] side channel… other than Bernstein, no public crypto projects are doing anything about this in a systematic way”. We’re approaching a point where localhost “nobody” will equate to key recovery.
Hasn’t this already happened? To try to date it, I would put it at 2001. That makes the prediction better suited to y2k. (The fact the file DPA.pdf on my storage media in use has a November 2001 creation date might be secretly influencing me here. That would be unfortunate.)
Besides all the stories of side channel attacks used by spies, side channel attacks went quite mainstream with research and attack demonstrations on smartcards a few years back. I can remember a couple of RSA conferences ago when there was a demonstration of SPA on the showroom floor, and most (all?) smartcard vendors have now tried to implement some sorts of countermeasures for the various attacks that have surfaced publicly (and not so publicly). I remember this making the news as well, which was probably as much due to the slight humor in flashing lights to induce faults as to the publicity around SPA/DPA attacks on smartcards. I noticed that government procurement specialists started requesting smartcards have countermeasures for these sorts of attacks at some point during this period as well. Recently, side channel attacks and their testing were discussed in numerous papers at the physical security workshop by the CMVP for possible inclusion in future evolutions of the program.
If that is not mainstream enough, then we need to throw in the timing analysis attacks on OpenSSL a couple of years ago (wow, has it been that long?). And then, of course, the AES cache timing analysis attacks demonstrated on OpenSSL this year, which prompted this 2006 prediction.
This is by no means comprehensive, and these are the bigger news items on this topic that stuck out in my mind when reading the prediction. These types of attacks will continue to be extended and to grow in application, which will bring them back into the news, but I think they went mainstream a long time ago.
(Side note: This is useful; however, I just wanted to be useless and comment on the file name. As is my tendency, I am quite amused. My peers and I use the term “black bag job” quite a bit in our lingo and have for years.)
Update: Thomas Ptacek explains I went in the wrong direction when reading his prediction.
Your points are well taken, but I think the underlying point I’m trying to make is, the number of real-world attacks on general-purpose hosts that have been carried out using side-channel attacks is zero.
I expect that to change in 2006.
Ahh, I see your point now. Side channel attacks and their countermeasures became a popular, public research area starting in the 1990’s and were spotlighted in the earlier part of this decade; however, these attacks certainly have not gotten into the public drivers seat for attacking the mass of general purpose hosts out there. From that perspective, I go in the opposite direct – I think side channel attacks will remain in the, well, trunk in 2006. The research will continue, demonstrations will happen on known tools, countermeasures will be developed, etc., but I just don’t see these attacks going mainstream in your terms next year, as these attacks are just not yet as useful as others.
[...] This will mean that the basic use of cryptography in certain portions of OpenSSL have been audited by a third party and found to meet a baseline set of security requirements as defined by NIST (FIPS 140-2). (No, common coding errors, timing attacks, etc. are not included in that audit, and, yes, this is a small view of the world the module may actually be used in.) Details on what has been taken through validation and the areas looked at can be found in the Security Policy for the OpenSSL module, and this document makes for quite an interesting read, especially with regards to the definition of the module and its integrity check, which shakes up prior interpretations a bit. [...]
[...] discussion and something I commented on a while back when misinterpreting a prediction by Ptacek. Besides all the stories of side [...]