Essentially you'd have to audit the entire cpu design to be sure that you didn't leave any fat fingerprints all over the place. Any flip-flop that had changed state in a recoverable way would be a potential security leak.
Good luck getting that kind of access to a cpu design though, and even better luck trying to figure out all the angles of attack, miss one and someone else has a vector, silicon is hard to change after the fact.
What is interesting here to me about this whole subject is that it has apparently long ago gone from 'theoretical' to 'practical', and you'd be hard pressed to prove that you didn't lose a key or two (or all of them) to an attacker sophisticated enough to do his snooping and then disappear quietly.
After all, any hack or hacker that you read about or hear about wasn't as good as they could have been, the ones you never hear about are the ones to worry about.
For me this whole idea of having someone plant a piece of software on a machine that I own without me detecting it was a prime reason in choosing not to do my own card processing (even though in the dark ages I wrote 'webpay', which later became the foundation for a major IPSP).
I realized that by simply having a page hosted that accepts credit cards on a https connection I would basically be putting up an open 'hack me' invite.
You want to google "Remote Timing Attacks Are Practical", which is the landmark paper in this subfield and also the one crypto people use to scare their children around campfires with.
What you're really observing is the flip side of the "covert channel problem", which has been a well-known Hard Problem driving systems research since the '70s (it's part of Saltzer/Schroeder). Systems security people generally concede that the covert channel problem is impractical to solve in theory, and have resigned themselves to occasional fire drills as theory becomes practice.
And even better, the Crosby article on optimizing timing attacks. He gets to the level of measuring differences as small as 15-100 microseconds over the Internet and 100 nanoseconds over the LAN.
Maybe I'm thinking about this too simply, but wouldn't fugding the timing on any cryptographic operation in a random fashion make it (much) harder to deduce the keys ?
No. This is basic signal processing. Increase the noise, and all you do is increase the number of measurements needed to recover the signal.
This is a really common misconception about defeating timing attacks.
A more pernicious problem is that many of these microarch side channel attacks don't rely on direct timing of crypto code, so much as on microarch artifacts.
(For what it's worth, the specifics beyond this get to a place where I'm out of my depth and Colin and Nate are still in theirs.)
Right, I get that, increase the noise by a factor of two and you'd need more samples, increasing the chance of detection but ultimately not making the problem much harder.
But every factor of two that you make it harder is effectively one bit extra on the key that you're trying to find right ?
Assuming that's true (going out on a limb here) the more you are willing to waste time the harder it will get for an attacker to recover the keys, so ultimately it is a measure of efficiency vs security.
As for micro architecture, I don't know much about that other than reading up on the 68K when it came out and how it functioned at the block level, but one way to side-step that issue completely if you want to write bullet proof crypto code (if that is even possible) would be to write it for a controller on a separate plug in card (pci, possibly usb) that would be permitted to allow exactly one crypto operation per fixed interval of time to be performed.
That way you could effectively 'hide' the key and all its side-effects from view from both local and remote attackers.
It would then take at a minimum physical access to the card to monitor its buses in order to recover they keys.
Good luck getting that kind of access to a cpu design though, and even better luck trying to figure out all the angles of attack, miss one and someone else has a vector, silicon is hard to change after the fact.
What is interesting here to me about this whole subject is that it has apparently long ago gone from 'theoretical' to 'practical', and you'd be hard pressed to prove that you didn't lose a key or two (or all of them) to an attacker sophisticated enough to do his snooping and then disappear quietly.
After all, any hack or hacker that you read about or hear about wasn't as good as they could have been, the ones you never hear about are the ones to worry about.
For me this whole idea of having someone plant a piece of software on a machine that I own without me detecting it was a prime reason in choosing not to do my own card processing (even though in the dark ages I wrote 'webpay', which later became the foundation for a major IPSP).
I realized that by simply having a page hosted that accepts credit cards on a https connection I would basically be putting up an open 'hack me' invite.