Oh noes, my microchipses!
-
According to this article, your microchips could be flawed, and hackers could break into them.
Yes, that's right. Hackers breaking into your computer chips.
From the article,
"Mr Seifert's research envisages that hackers will find it far easier and quicker in the future using a small piece of spy software that tracks microchips. In a still-confidential study, Mr Seifert and his colleagues explain how they managed "in only one attempt" to obtain a 512-bit encryption key in just a few thousandths of a second."
Gee, this sounds impressive."Mr Seifert plans to demonstrate his method at the beginning of 2007 at an conference on encryption."
As interesting as it promises to be, I think I might just pass on that conference.
Props to mazzanet for discovering this hideous little atrocity.
-
http://eprint.iacr.org/2006/351
Modern CPUs do all sorts of clever things to speed up the process of fetching instructions from memory, reading data, executing the instruction and possibly writing back to memory, including branch prediction - reading what's hopefully the right bit of code before it's required, keeping the pipeline nice and full.
What these guys are apparently doing is interrupting the CPU frequently while they know it's running an RSA algorithm, and looking at what state it's in - ie. if you know the algorithm and you know what state the machine is in, the only unknown is the algorithm's parameters, including the key.
So yes, potentially "hacking your microchips", though it'll take a good few years before everyday spyware is capable, which, like y2k, is way too far off to worry about...
-
[quote user="Vector"]
According to this article, your microchips could be flawed, and hackers could break into them.
Yes, that's right. Hackers breaking into your computer chips.
From the article,
"Mr Seifert's research envisages that
hackers will find it far easier and quicker in the future using a small
piece of spy software that tracks microchips. In a still-confidential study, Mr Seifert
and his colleagues explain how they managed "in only one attempt" to
obtain a 512-bit encryption key in just a few thousandths of a second."
[/quote]
Gee, this sounds impressive.It's WTF-worthy reporting of a serious problem. RSA, like most encryption algorithms, is potentially vulnerable to side-channel attacks: figuring out the message or encryption key not by attacking the algorithm directly, but by analyzing byproducts of the encryption process. In the case of smartcards, this was done first by measuring the heat production as the card encrypted something, and later by measuring the radio noise produced. For RSA on computers, the key can be determined by measuring the branch-prediction behaviour of the CPU. The original attack of this form required analyzing several thousand encryptions; this new attack only requires one.For home computers, this might not be a threat, since it's easier just to grab the key off the hard drive. On multi-user systems, however, this lets Eve grab Bob's encryption key, even though she doesn't have access to either his files or his process space.
-
[quote user="versatilia"]
On the Power of Simple Branch Prediction Analysis
Very recently, a new software side-channel attack, called Branch Prediction Analysis (BPA) attack, has been discovered and also demonstrated to be practically feasible on popular commodity PC platforms. While the above recent attack still had the flavor of a classical timing attack against RSA,...
What these guys are apparently doing is interrupting the CPU frequently while they know it's running an RSA algorithm, and looking at what state it's in - ie. if you know the algorithm and you know what state the machine is in, the only unknown is the algorithm's parameters, including the key.
[/quote]
If you can interrupt the CPU and query its state, and you know the algorithm, why not just read the private RSA key bits directly? If they calculation is being done on a smartcard, then interrupting the state of the computer's CPU won't help (you want the state of the branch prediction on the smartcard, not the state on the local computer's CPU). I'd much rather reproduce a key from deciphering the registers than by deciphering taken/not-taken branch trace.
So what am I missing?
-
1. The authors of the attack vector released little information beyond: "micro-code-level", "encryption", "cracked", "undetectable", ...
2. A journalist then filled in the gaps using a thesaurus and babelfish.
The result is that article. Take it with a grain of salt and try not to ridicule the guys behind it yet.
-
[quote user="darin"]
If you can interrupt the CPU and query its state, and you know the algorithm, why not just read the private RSA key bits directly?
So what am I missing?
[/quote]
They aren't querying the state. They're running some of their own code on the CPU, which still contains old data in the BTB, but not any of the register values. By observing the performance of their own code, they can infer the old contents of the BTB. This lets them deduce what the key is.
Their attack only works on a particular breed of P4, but it's ingenious and can probably be applied to other chips. Security holes in the chip's own performance caching is something that people don't often consider, and it's a big deal when dealing with a system that's supposed to run trusted and untrusted code on the same hardware. Consider for a moment the implications if somebody could get this working in a 'sandboxed' language like javascript - nobody's done it yet, but someday they might.
-
[quote user="asuffield"]
They aren't querying the state. They're running some of their own code on the CPU, which still contains old data in the BTB, but not any of the register values. By observing the performance of their own code, they can infer the old contents of the BTB. This lets them deduce what the key is.
[/quote]
Interesting. I'm surprised this data isn't cleared on a context switch, or is there a possibility that the processor could switch back soon enough for it to still be useful? I don't know a great detail about such things, as you can probably guess. :-) Anyway, is there any chance the kernel could explicitly force the data to be cleared?
-
Uhm, how do they interrupt the cpu? With special drivers? Special hardware? It cannot be just a context switch as this is doing so much on the cpu that every possible state is lost. So when you nevertheless have to inject those special tools, it will be far easier to directly get the key from the memory or hdd, since you would need special priviliges for interrupting the cpu that way.
-
I remember years ago hearing about someone who discovered a way to snoop on an IBM Selectric typewriter.
The Selectric had a single electric motor running constantly and everything about it was completely mechanical. Pressing a key would activate levers and cams to rotate the ball along two dimensions to position the letter to be typed. Evidently the load on the motor was different for each letter and this made enough difference in the radio-frequency emissions of the motor to be detected from the next room.
-
[quote user="PlasmaHH"]Uhm, how do they interrupt the cpu? With special drivers? Special hardware? It cannot be just a context switch as this is doing so much on the cpu that every possible state is lost. So when you nevertheless have to inject those special tools, it will be far easier to directly get the key from the memory or hdd, since you would need special priviliges for interrupting the cpu that way.
[/quote]IIRC, they don't interrupt the CPU. The exploit only works on P4 CPUs with hyperthreading, and the exploit code just runs on a different logical processor.
