Posted: 12/18/2013 6:04:51 PM EDT
|
http://arstechnica.com/security/2013/12/new-attack-steals-e-mail-decryption-keys-by-capturing-computer-sounds/
Well that's interesting. I wonder if it works on an machine that has its motherboard encased in circuit potting resin. |
|
I question this. Why? Because they say they're doing it in audio frequencies. It doesn't make any sense. Assuming your PC is a slow 2 GHz machine with an outdated 800 MHz frontside bus and 233 MHz RAM speed, which is a SLOW machine by modern standards, then it would take, let's be generous, 8192 clock cycles to read out a 4096 bit RSA key from RAM. 233 million divided by 8192 is 28442, so you could pass 28442 such 8192 bit long sequences per second. A single sequence of 8192 bits would take 3.515E-05 seconds to complete and the ENTIRE sequence happens in 1/28442th of a second. It's a very fine microphone indeed that can even pick up a signal higher than 50 KHz and in this case the entire 8192 bit data stream is packed into a single 28442th of a second. The microphone would have to be able to hear audio at frequencies of 233 MHz or a heck of a lot faster on a really modern machine. Individual bits would take just 4.3 nanoseconds to pass. These sounds ALL occur at frequencies as high as the bus clock speeds of the computer. The point is that ALL of this happens so fast that it's BEYOND the audio frequency range of even the BEST audio recording equipment. I don't see any reason why any encryption software would NOT access its encryption key at anything less than the fastest available data transfer rate from the RAM bus. And not only that, but we're not even talking about a SINGLE data stream to listen in on. Any reasonable PC today is a true 32 bit machine, if not a 64 bit machine, and thus you're looking at a HUGE number of concurrent data streams coming and going between all the various chips in the computer and that makes the art of listening to and successfully decoding the sounds geometrically more complex. Frankly I call bullshit. The more I think about it, the LESS likely that article is to be based in fact. I no longer believe it AT ALL. There are WAY too many holes in the theory. It looks like swiss cheese being used as a target at a skeet tournament. |
|
If they spend a shitload of time with the target computer and develop a profile of all the different oscillations that it goes through while it's processing known data I can see this being possible. But it seems to me like it would be so impractical that it doesn't matter.
|
|
Quoted: first post didn't read the fucking article very carefully. Quoted: Quoted: FPNI first post didn't read the fucking article very carefully. The problems I described are still present. One, the data transfer rate is in hundreds of MHz, FAR outside the range of even their best named microphone, and second, the acoustic noise created by the power supply components would be the average of the power fluctuations being generated by literally hundreds of parallel data streams running between the CPU, RAM, and every other chip on the board. I simply don't believe it. I believe that if you were to duplicate the described test setup you would encounter only failure. |
|
Quoted:
I scanned it. Meaning, I didn't read every word but I reviewed a lot of it. The problems I described are still present. One, the data transfer rate is in hundreds of MHz, FAR outside the range of even their best named microphone, and second, the acoustic noise created by the power supply components would be the average of the power fluctuations being generated by literally hundreds of parallel data streams running between the CPU, RAM, and every other chip on the board. I simply don't believe it. I believe that if you were to duplicate the described test setup you would encounter only failure. I would tend to agree, but if the article is to be believed, they stated they were able to crack a key on a T61 (not ancient by any means) with a smartphone mic and an hour of cryptanalysis. |
|
Quoted:
I question this. Why? Because they say they're doing it in audio frequencies. It doesn't make any sense. Assuming your PC is a slow 2 GHz machine with an outdated 800 MHz frontside bus and 233 MHz RAM speed, which is a SLOW machine by modern standards, then it would take, let's be generous, 8192 clock cycles to read out a 4096 bit RSA key from RAM. 233 million divided by 8192 is 28442, so you could pass 28442 such 8192 bit long sequences per second. A single sequence of 8192 bits would take 3.515E-05 seconds to complete and the ENTIRE sequence happens in 1/28442th of a second. It's a very fine microphone indeed that can even pick up a signal higher than 50 KHz and in this case the entire 8192 bit data stream is packed into a single 28442th of a second. The microphone would have to be able to hear audio at frequencies of 233 MHz or a heck of a lot faster on a really modern machine. Individual bits would take just 4.3 nanoseconds to pass. These sounds ALL occur at frequencies as high as the bus clock speeds of the computer. The point is that ALL of this happens so fast that it's BEYOND the audio frequency range of even the BEST audio recording equipment. I don't see any reason why any encryption software would NOT access its encryption key at anything less than the fastest available data transfer rate from the RAM bus. And not only that, but we're not even talking about a SINGLE data stream to listen in on. Any reasonable PC today is a true 32 bit machine, if not a 64 bit machine, and thus you're looking at a HUGE number of concurrent data streams coming and going between all the various chips in the computer and that makes the art of listening to and successfully decoding the sounds geometrically more complex. Frankly I call bullshit. The more I think about it, the LESS likely that article is to be based in fact. I no longer believe it AT ALL. There are WAY too many holes in the theory. It looks like swiss cheese being used as a target at a skeet tournament. This. |
|
Quoted:
I question this. Why? Because they say they're doing it in audio frequencies. It doesn't make any sense. Assuming your PC is a slow 2 GHz machine with an outdated 800 MHz frontside bus and 233 MHz RAM speed, which is a SLOW machine by modern standards, then it would take, let's be generous, 8192 clock cycles to read out a 4096 bit RSA key from RAM. 233 million divided by 8192 is 28442, so you could pass 28442 such 8192 bit long sequences per second. A single sequence of 8192 bits would take 3.515E-05 seconds to complete and the ENTIRE sequence happens in 1/28442th of a second. It's a very fine microphone indeed that can even pick up a signal higher than 50 KHz and in this case the entire 8192 bit data stream is packed into a single 28442th of a second. The microphone would have to be able to hear audio at frequencies of 233 MHz or a heck of a lot faster on a really modern machine. Individual bits would take just 4.3 nanoseconds to pass. These sounds ALL occur at frequencies as high as the bus clock speeds of the computer. The point is that ALL of this happens so fast that it's BEYOND the audio frequency range of even the BEST audio recording equipment. I don't see any reason why any encryption software would NOT access its encryption key at anything less than the fastest available data transfer rate from the RAM bus. And not only that, but we're not even talking about a SINGLE data stream to listen in on. Any reasonable PC today is a true 32 bit machine, if not a 64 bit machine, and thus you're looking at a HUGE number of concurrent data streams coming and going between all the various chips in the computer and that makes the art of listening to and successfully decoding the sounds geometrically more complex. Frankly I call bullshit. The more I think about it, the LESS likely that article is to be based in fact. I no longer believe it AT ALL. There are WAY too many holes in the theory. It looks like swiss cheese being used as a target at a skeet tournament. Adi Shamir, the "S" in RSA signed off on this paper. The man invented the shit. If he says its so, I believe it. Note that the key to my mind is that its a chosen plaintext attack. I think they adaptively select plaintexts with repeated sequences designed to deal with the sampling issue you mention. Plus go read the article -- they're actually picking up distinctive audio signatures for the processing of discreet cpu instructions. Its fascinating. Remember that RSA (also elliptical curve) are basically techniques utilizing very large numbers. Unique numbers. These numbers create a particular audio profile apparently. They figure out the key one bit at a time. Since its a chosen plaintext attack, its still worthless against my air-gap machine that gets data to decrypt only in the form of PGP text files received on my net connected machine and transferred to the air gap machine via old fashioned 3.5" floppy. Again, if Shamir says this is a real deal, its the real deal. |
|
Quoted:
I scanned it. Meaning, I didn't read every word but I reviewed a lot of it. The problems I described are still present. One, the data transfer rate is in hundreds of MHz, FAR outside the range of even their best named microphone, and second, the acoustic noise created by the power supply components would be the average of the power fluctuations being generated by literally hundreds of parallel data streams running between the CPU, RAM, and every other chip on the board. I simply don't believe it. I believe that if you were to duplicate the described test setup you would encounter only failure. Quoted:
Quoted:
Quoted:
FPNI first post didn't read the fucking article very carefully. The problems I described are still present. One, the data transfer rate is in hundreds of MHz, FAR outside the range of even their best named microphone, and second, the acoustic noise created by the power supply components would be the average of the power fluctuations being generated by literally hundreds of parallel data streams running between the CPU, RAM, and every other chip on the board. I simply don't believe it. I believe that if you were to duplicate the described test setup you would encounter only failure. You should read the paper. It thoroughly addresses your issues, and I think it does it on the first page if I remember correctly. |
|
The information on the lower half of page 4 contains the most relevant data. So what they're saying is that they were creating keys specifically engineered to generate low frequency, audio range data. Long strings of zeros in the key output, in essence. Well, I can believe that. But is it a real world scenario? No, I don't think it is. If their attack won't work on any given randomly chosen key, but only works on keys that are the equivalent of a stacked deck, then it's not much of an attack, is it? Their method won't work on keys that don't generate that low frequency output, which I would venture to guess is the vast majority of all possible keys. |
|
Quoted:
Adi Shamir, the "S" in RSA signed off on this paper. The man invented the shit. If he says its so, I believe it. Note that the key to my mind is that its a chosen plaintext attack. I think they adaptively select plaintexts with repeated sequences designed to deal with the sampling issue you mention. Plus go read the article -- they're actually picking up distinctive audio signatures for the processing of discreet cpu instructions. Its fascinating. Remember that RSA (also elliptical curve) are basically techniques utilizing very large numbers. Unique numbers. These numbers create a particular audio profile apparently. They figure out the key one bit at a time. Since its a chosen plaintext attack, its still worthless against my air-gap machine that gets data to decrypt only in the form of PGP text files received on my net connected machine and transferred to the air gap machine via old fashioned 3.5" floppy. Again, if Shamir says this is a real deal, its the real deal. Quoted:
Quoted:
I question this. Why? Because they say they're doing it in audio frequencies. It doesn't make any sense. Assuming your PC is a slow 2 GHz machine with an outdated 800 MHz frontside bus and 233 MHz RAM speed, which is a SLOW machine by modern standards, then it would take, let's be generous, 8192 clock cycles to read out a 4096 bit RSA key from RAM. 233 million divided by 8192 is 28442, so you could pass 28442 such 8192 bit long sequences per second. A single sequence of 8192 bits would take 3.515E-05 seconds to complete and the ENTIRE sequence happens in 1/28442th of a second. It's a very fine microphone indeed that can even pick up a signal higher than 50 KHz and in this case the entire 8192 bit data stream is packed into a single 28442th of a second. The microphone would have to be able to hear audio at frequencies of 233 MHz or a heck of a lot faster on a really modern machine. Individual bits would take just 4.3 nanoseconds to pass. These sounds ALL occur at frequencies as high as the bus clock speeds of the computer. The point is that ALL of this happens so fast that it's BEYOND the audio frequency range of even the BEST audio recording equipment. I don't see any reason why any encryption software would NOT access its encryption key at anything less than the fastest available data transfer rate from the RAM bus. And not only that, but we're not even talking about a SINGLE data stream to listen in on. Any reasonable PC today is a true 32 bit machine, if not a 64 bit machine, and thus you're looking at a HUGE number of concurrent data streams coming and going between all the various chips in the computer and that makes the art of listening to and successfully decoding the sounds geometrically more complex. Frankly I call bullshit. The more I think about it, the LESS likely that article is to be based in fact. I no longer believe it AT ALL. There are WAY too many holes in the theory. It looks like swiss cheese being used as a target at a skeet tournament. Adi Shamir, the "S" in RSA signed off on this paper. The man invented the shit. If he says its so, I believe it. Note that the key to my mind is that its a chosen plaintext attack. I think they adaptively select plaintexts with repeated sequences designed to deal with the sampling issue you mention. Plus go read the article -- they're actually picking up distinctive audio signatures for the processing of discreet cpu instructions. Its fascinating. Remember that RSA (also elliptical curve) are basically techniques utilizing very large numbers. Unique numbers. These numbers create a particular audio profile apparently. They figure out the key one bit at a time. Since its a chosen plaintext attack, its still worthless against my air-gap machine that gets data to decrypt only in the form of PGP text files received on my net connected machine and transferred to the air gap machine via old fashioned 3.5" floppy. Again, if Shamir says this is a real deal, its the real deal. This. chosen plaintext, and they explain in detail how they manipulate the system in order to force it to leak data. Shamir is pretty much a god when it comes to this shit. |
|
Quoted:
The information on the lower half of page 4 contains the most relevant data. So what they're saying is that they were creating keys specifically engineered to generate low frequency, audio range data. Long strings of zeros in the key output, in essence. Well, I can believe that. But is it a real world scenario? No, I don't think it is. If their attack won't work on any given randomly chosen key, but only works on keys that are the equivalent of a stacked deck, then it's not much of an attack, is it? Their method won't work on keys that don't generate that low frequency output, which I would venture to guess is the vast majority of all possible keys. What do you do for a living? |
|
I'm an RF engineer/technician and I spend a lot of time working with digital radio systems, some of which is pure research so I can get a better understanding of the systems I have to work with. That includes encryption systems. The method outlined in the paper is very similar to what I do with an arbitrary function generator, in concept. They craft keys that generate audio range outputs that are detectable, and what I have done for specific test purposes is digitally generate data sequences that combine to create audio tones. It takes some time but I can hand craft a data stream to generate any given audio tone I wish, and sustain that tone for as long as I wish up to memory limits. The point is that their attack only works with a "stacked deck" and doesn't seem to be a viable real world attack against real world, (hopefully) randomly generated keys. |
|
Quoted:
The information on the lower half of page 4 contains the most relevant data. So what they're saying is that they were creating keys specifically engineered to generate low frequency, audio range data. Long strings of zeros in the key output, in essence. Well, I can believe that. But is it a real world scenario? No, I don't think it is. If their attack won't work on any given randomly chosen key, but only works on keys that are the equivalent of a stacked deck, then it's not much of an attack, is it? Their method won't work on keys that don't generate that low frequency output, which I would venture to guess is the vast majority of all possible keys. They're not generating special keys, but special plaintexts. The plaintextes are designed to create certain distinctive CPU code execution processes due to the inherent mathematics in RSA, which their audio analysis then permits them to evaluate to extract the RSA key a bit at a time. Later in the article they give a couple realistic vectors, for example, email programs that automatically decrypt incoming messages while the password is cached (and, I believe, taking advantage of GNUPGP's property where a cached password stays cached for "X" period after every successful use. Its a "break" in that it clearly allows under specified conditions the discernment of a key using a process easier than brute force. Also fascinating is the ability to extend the attack to capturing the signal in ground differentials present all the way at the remote end of a network cable, or via human contact with the chassis of the machine. From a cryptography standpoint this is ground breaking shit... through from a practical standpoint, as with all chosen plaintext attacks, very diligent user practices prevent it. As I mentioned above, I've got an airgapped machine that has no external connectivity of any kind. (I physically removed them). It gets files to decrypt only via a floppy drive. It would be pretty tough to "convince" me to decrypt enough chosen plaintext messages for this to be effective, even if they did have a microphone planted in very close proximity to my machine. |
|
Quoted:
I'm an RF engineer/technician and I spend a lot of time working with digital radio systems, some of which is pure research so I can get a better understanding of the systems I have to work with. That includes encryption systems. The method outlined in the paper is very similar to what I do with an arbitrary function generator, in concept. They craft keys that generate audio range outputs that are detectable, and what I have done for specific test purposes is digitally generate data sequences that combine to create audio tones. It takes some time but I can hand craft a data stream to generate any given audio tone I wish, and sustain that tone for as long as I wish up to memory limits. The point is that their attack only works with a "stacked deck" and doesn't seem to be a viable real world attack against real world, (hopefully) randomly generated keys. This kind of reminds me of CS project did which was a Pseudo Random Number Generator that used a mic and accelerometer to pick up ambient room noise and vibrations as a seed the generation algorithim. 
|
|
Quoted:
I'm an RF engineer/technician and I spend a lot of time working with digital radio systems, some of which is pure research so I can get a better understanding of the systems I have to work with. That includes encryption systems. The method outlined in the paper is very similar to what I do with an arbitrary function generator, in concept. They craft keys that generate audio range outputs that are detectable, and what I have done for specific test purposes is digitally generate data sequences that combine to create audio tones. It takes some time but I can hand craft a data stream to generate any given audio tone I wish, and sustain that tone for as long as I wish up to memory limits. The point is that their attack only works with a "stacked deck" and doesn't seem to be a viable real world attack against real world, (hopefully) randomly generated keys. In the paper they identified 5 randomly generated RSA private keys. But, you're correct in that they have to "stack the deck" in the sense that the audio leakage is unique to each computer, even the same model. So while keys can be identified and extracted, they have to do several passes with a known key to get the baseline. Also of note they're not getting audio leakage from the processor or bus, they're getting it from the power circuitry. |
|
Quoted:
Also bullshit. Not necessarily. If you read it, the infection vector seems to be USB. It's doable. Kind of surprises me that someone would be reloading infected systems and not catching they were using the same USB drives they had in an infected system, but I can believe the rest. |
|
Quoted: Not necessarily. If you read it, the infection vector seems to be USB. It's doable. Kind of surprises me that someone would be reloading infected systems and not catching they were using the same USB drives they had in an infected system, but I can believe the rest. Quoted: Not necessarily. If you read it, the infection vector seems to be USB. It's doable. Kind of surprises me that someone would be reloading infected systems and not catching they were using the same USB drives they had in an infected system, but I can believe the rest. Read some of the guy's ramblings. It's a bunch of delusional, incoherent bullshit. He's a fucking retard, plain and simple. At least the attack described in the OP of this thread has some merit, even if it's not practical. The badBIOS thing was like the woman that thinks that rainbows are a conspiracy to control her mind. |
|
Quoted:
Read some of the guy's ramblings. It's a bunch of delusional, incoherent bullshit. He's a fucking retard, plain and simple. At least the attack described in the OP of this thread has some merit, even if it's not practical. The badBIOS thing was like the woman that thinks that rainbows are a conspiracy to control her mind. Quoted:
Quoted:
Not necessarily. If you read it, the infection vector seems to be USB. It's doable. Kind of surprises me that someone would be reloading infected systems and not catching they were using the same USB drives they had in an infected system, but I can believe the rest. Read some of the guy's ramblings. It's a bunch of delusional, incoherent bullshit. He's a fucking retard, plain and simple. At least the attack described in the OP of this thread has some merit, even if it's not practical. The badBIOS thing was like the woman that thinks that rainbows are a conspiracy to control her mind. I'm not saying he's right. I'm just not ready to say bullshit. What they're saying is theoretically possible. Highly unlikely, but possible. The thing I caught was the reuse of flash drives between uninfected and infected systems. That's an OLD problem that goes back to floppy based virus infections. A basic infection that hits a few common pieces of hardware just enough to ask for something more complicated could happen. Sounded like sloppy work and reinfecting his "clean" systems to me if the virus is real. |
|
Quoted:
Not necessarily. If you read it, the infection vector seems to be USB. It's doable. Kind of surprises me that someone would be reloading infected systems and not catching they were using the same USB drives they had in an infected system, but I can believe the rest. Quoted:
Not necessarily. If you read it, the infection vector seems to be USB. It's doable. Kind of surprises me that someone would be reloading infected systems and not catching they were using the same USB drives they had in an infected system, but I can believe the rest. No, badbios is pretty much bullshit. There's a paper written by a bios programmer that pretty much completely discredits it. |
|
Quoted: In the paper they identified 5 randomly generated RSA private keys. But, you're correct in that they have to "stack the deck" in the sense that the audio leakage is unique to each computer, even the same model. So while keys can be identified and extracted, they have to do several passes with a known key to get the baseline. Also of note they're not getting audio leakage from the processor or bus, they're getting it from the power circuitry. To say that they're "stacking the deck" is a major understatement. You basically have to be able to profile THAT particular computer with THAT specific algorithm with neatly generated HALT states in between, etc. etc. I'll buy that they can profile looped instructions such as HALT, or maybe ADD, but can they distinguish a XOR from an ADD or an SHFTLFT. Or how about a MUL from a SSE instruction? I'm going to finish reading the paper later tonight, but right now I'm still having a hard time comprehending how they got from "this looks like the time frame where the encryption should be happening" to "these are the encrypted bits". |
|
Quoted:
No, badbios is pretty much bullshit. There's a paper written by a bios programmer that pretty much completely discredits it. Quoted:
Quoted:
Not necessarily. If you read it, the infection vector seems to be USB. It's doable. Kind of surprises me that someone would be reloading infected systems and not catching they were using the same USB drives they had in an infected system, but I can believe the rest. No, badbios is pretty much bullshit. There's a paper written by a bios programmer that pretty much completely discredits it. Good. I don't want to have to deal with a virus like that, or maybe I do. "Your network is infected. You need to take it and all of your storage media out in the parking lot and burn it w/ thermite. After you have done that, we'll price a new network for you!"  Way easier to delouse!
|
|
Quoted:
I'm not saying he's right. I'm just not ready to say bullshit. What they're saying is theoretically possible. Highly unlikely, but possible. The thing I caught was the reuse of flash drives between uninfected and infected systems. That's an OLD problem that goes back to floppy based virus infections. A basic infection that hits a few common pieces of hardware just enough to ask for something more complicated could happen. Sounded like sloppy work and reinfecting his "clean" systems to me if the virus is real. Quoted:
Quoted:
Quoted:
Not necessarily. If you read it, the infection vector seems to be USB. It's doable. Kind of surprises me that someone would be reloading infected systems and not catching they were using the same USB drives they had in an infected system, but I can believe the rest. Read some of the guy's ramblings. It's a bunch of delusional, incoherent bullshit. He's a fucking retard, plain and simple. At least the attack described in the OP of this thread has some merit, even if it's not practical. The badBIOS thing was like the woman that thinks that rainbows are a conspiracy to control her mind. I'm not saying he's right. I'm just not ready to say bullshit. What they're saying is theoretically possible. Highly unlikely, but possible. The thing I caught was the reuse of flash drives between uninfected and infected systems. That's an OLD problem that goes back to floppy based virus infections. A basic infection that hits a few common pieces of hardware just enough to ask for something more complicated could happen. Sounded like sloppy work and reinfecting his "clean" systems to me if the virus is real. Some of the individual things (in fact most of them) are possible. The combination of them, and in particular the crossover between different bios and such is really not. |
|
Quoted:
To say that they're "stacking the deck" is a major understatement. You basically have to be able to profile THAT particular computer with THAT specific algorithm with neatly generated HALT states in between, etc. etc. I'll buy that they can profile looped instructions such as HALT, or maybe ADD, but can they distinguish a XOR from an ADD or an SHFTLFT. Or how about a MUL from a SSE instruction? I'm going to finish reading the paper later tonight, but right now I'm still having a hard time comprehending how they got from "this looks like the time frame where the encryption should be happening" to "these are the encrypted bits". Quoted:
Quoted:
In the paper they identified 5 randomly generated RSA private keys. But, you're correct in that they have to "stack the deck" in the sense that the audio leakage is unique to each computer, even the same model. So while keys can be identified and extracted, they have to do several passes with a known key to get the baseline. Also of note they're not getting audio leakage from the processor or bus, they're getting it from the power circuitry. To say that they're "stacking the deck" is a major understatement. You basically have to be able to profile THAT particular computer with THAT specific algorithm with neatly generated HALT states in between, etc. etc. I'll buy that they can profile looped instructions such as HALT, or maybe ADD, but can they distinguish a XOR from an ADD or an SHFTLFT. Or how about a MUL from a SSE instruction? I'm going to finish reading the paper later tonight, but right now I'm still having a hard time comprehending how they got from "this looks like the time frame where the encryption should be happening" to "these are the encrypted bits". Read the paper -- I didn't believe it at first either. |
|
Quoted: Read the paper -- I didn't believe it at first either. Quoted: Quoted: Quoted: In the paper they identified 5 randomly generated RSA private keys. But, you're correct in that they have to "stack the deck" in the sense that the audio leakage is unique to each computer, even the same model. So while keys can be identified and extracted, they have to do several passes with a known key to get the baseline. Also of note they're not getting audio leakage from the processor or bus, they're getting it from the power circuitry. To say that they're "stacking the deck" is a major understatement. You basically have to be able to profile THAT particular computer with THAT specific algorithm with neatly generated HALT states in between, etc. etc. I'll buy that they can profile looped instructions such as HALT, or maybe ADD, but can they distinguish a XOR from an ADD or an SHFTLFT. Or how about a MUL from a SSE instruction? I'm going to finish reading the paper later tonight, but right now I'm still having a hard time comprehending how they got from "this looks like the time frame where the encryption should be happening" to "these are the encrypted bits". Read the paper -- I didn't believe it at first either. I've read the paper. As an electrical engineer, a CPU architect even, I still don't buy all they're selling. That's not to say I know much about encryption algorithms. |
|
Quoted:
I've read the paper. As an electrical engineer, a CPU architect even, I still don't buy all they're selling. That's not to say I know much about encryption algorithms. Quoted:
Quoted:
Quoted:
Quoted:
In the paper they identified 5 randomly generated RSA private keys. But, you're correct in that they have to "stack the deck" in the sense that the audio leakage is unique to each computer, even the same model. So while keys can be identified and extracted, they have to do several passes with a known key to get the baseline. Also of note they're not getting audio leakage from the processor or bus, they're getting it from the power circuitry. To say that they're "stacking the deck" is a major understatement. You basically have to be able to profile THAT particular computer with THAT specific algorithm with neatly generated HALT states in between, etc. etc. I'll buy that they can profile looped instructions such as HALT, or maybe ADD, but can they distinguish a XOR from an ADD or an SHFTLFT. Or how about a MUL from a SSE instruction? I'm going to finish reading the paper later tonight, but right now I'm still having a hard time comprehending how they got from "this looks like the time frame where the encryption should be happening" to "these are the encrypted bits". Read the paper -- I didn't believe it at first either. I've read the paper. As an electrical engineer, a CPU architect even, I still don't buy all they're selling. That's not to say I know much about encryption algorithms. The basic gist, the RSA private key can be derived if you know a couple of variables in the algorithm, if I remember correctly it's p and q, Josh will correct me if I'm wrong; what they did was not capture the entire key but capture what the bits used for p and q are down to several possibilities, then brute forced the key out of the narrowed scope. Basically they took the key from a near infinite number of possibilities to a few hundred thousand that could be chewed on for about an hour to figure out the key. |
|
Quoted: The basic gist, the RSA private key can be derived if you know a couple of variables in the algorithm, if I remember correctly it's p and q, Josh will correct me if I'm wrong; what they did was not capture the entire key but capture what the bits used for p and q are down to several possibilities, then brute forced the key out of the narrowed scope. Basically they took the key from a near infinite number of possibilities to a few hundred thousand that could be chewed on for about an hour to figure out the key. I got that part too, but there are a lot of things unexplained. There is a quantum leap being made that's similar as the jump from 1+1=2 to calculus in one chapter. |
