Looking for a pattern, that's why it takes an hour. You're looking for a pattern in the noise that repeats, then looking for subtle variations in the pattern to pick out the specific bits. There's a lot of other noise from other sources, but if you listen long enough, you know the length and frequency of the pattern you're looking for, you'll still be able to pick it out.

This won't work as something that happens in a one off, and you still need the target machine to be compromised to be repeatably getting the pattern to be created in the first place. That said, it is still impressive, and it shows that the target algorithm needs more randomization, which is the fix that was mentioned. I do this in firmware that I write, I don't hide the private keys all in one variable, I have them cut apart in pieces so that you can't just read my firmware and try every contiguous 4,096 bit block and see if it's my private key.

Just to help expand on the noise source, it's coming from the change in current associated with the transistors, I'm not sure why the paper didn't mention that as clearly. For example, a transistor is going to be either on (value = 1) or off (value = 0). As you might guess, it takes more current to have a transistor in the on position! When there's billions of transistors, the amount of current for each transistor is pretty small. But if you get a bunch of them to line up all at once (lots of 1's or lots of 0's, as they mention), you start to get a measurable current change.

That's what's being heard. In points of the math algorithm, the current drawn by those 1's and 0's is changing, and it's changing in a repeatable way because of the math loops. That change in current draw is seen by the power supply, and pieces of the power supply end up making noise as a result, because the change in current draw is large enough for a long enough period of time.

An easy example you might recognize is a fluorescent light that's running on the 60Hz signal. If the light starts to die, you're starting to see varying amounts of current being drawn, which translate to a noise being heard. The CPU is doing exactly the same thing.

As far as the signal specs itself, the paper was looking up to ~300kHz, iirc. I don't remember the dynamic range, but because they were examining the frequency content and not just the overall signal power, it gets a lot easier to pick up on the tones.

Ok, I'm impressed.

For those that didn't want to RTFA, this works by letting the target computer spin on a carefully chosen piece of text. That text is chosen such that the CPU will do some predictable math (such as big equations that == 0). Then, those places where the CPU hits 0 can be heard through a sensitive microphone.

The neat part is that you're not looking for a 4096-bit key. Computers don't actually handle things with that large of a size, they have to break it down into 32-bit/64-bit chunks to be able to do the math. That's the real vulnerability - despite the key length itself being massive, because the number gets broken down into small chunks, you can start to handle it. The paper goes through a very complicated way of sensing each section of a large key, and then piecing it all together. This is not a case of hearing a specific noise, and looking it up in a table. It's not even a case of looking up 32-bit chunks in a table.

So, it is a real attack, that is mostly dependent on the breakdown of the 4096bit key into bitesize chunks, that go through known math routines. If you can get the target to nicely decrypt several well-crafted messages for you, and you can get a good microphone near their CPU while they do it, and you can let this process go on long enough (so the attack program can listen to the CPU for a while to build up a profile, etc.), it really can work.

I'll say that it needs kind of an ideal scenario to get all those things lined up, but it's not impossible.

Preventing it fully is really only possible with two ways. Either switch your CPU to not use those bite-size chunks, and have the decryption take place all in one massive math operation (not realistic), or change the math that occurs on the bite-size chunks to be irregular in terms of any recognizable patterns (very realistic).

Costs are somewhat protected right now, but it was less than 75k. And since it's a prototype and not a full company, yes, there really is no warranty (unlike the motorbike project, where there is).

Range is also a negotiable thing, to a point - this doesn't get as much as the Tesla (yet?) but it doesn't need to. He can commute to and from work, and then some, and charge up. Considering charge times take in the minutes with the right setup, that's plenty. It's a pretty small group of people that are driving more than 200 miles everyday without stopping for a charge.

The other nice thing is that since we already have the gas station infrastructure in place, it can be converted to charging stations. With the right setup, you can charge this kind of car in mere minutes (think 15 minutes). All this means is that while the 200 mile range is nice, it's unneeded and a waste of money.

I certainly grant that Green Vehicles aimed too high, but that was their error. There are already 3 wheel vehicles around, why not use one of those? What about starting with one of the new Can-Am Spyder and turning that into an electric?

The question here isn't whether or not the entire car concept sucks - it doesn't. 100 years have proven that car transportation works pretty well to get from place to place. The only issue is how to propel it. Trying to start "ground up" on that is pretty silly.

I'm not claiming that my buddy has made a brand new car. I'm claiming that for under $500k, he has made a road worthy prototype, nothing more. Clearly he needs more work and investment if it's going to become the next Tesla (or better, hopefully!).

The thing people forget is that we have 100 years of car design - why throw that out the window? Certainly there are cheaper cars he could have picked to start from. Regardless, it's a prototype, nothing more.

And I certainly knew he did the conversion, duh. Though how much of it is a conversion and how much is a new design starts to blur when you remove half the stuff inside. He didn't design the chemical composition in the battery packs either, would those count as conversion? At some point, every company buys parts from another to make their product when it comes to consumer stuff. In his case, he bought a car "shell" and used that to hold everything else.

Ok the Porche comment was a bit much I guess, but you get the idea.

But why bother designing an entire auto? Yes he started with a stock car, but there's nothing wrong with that. The question here isn't whether or not you can design something ground up, it's whether you can make a good electric car. Same deal for his electric bike - motorbike design is decades old, don't mess with that section, just do the electric parts.

The OP was trying to make a prototype for under $500k - that's what this is, nothing more. I'm only saying that they failed miserably in that task, and should not have. I don't claim that this car is the end-all of electric car designs, or that it is going to be the next big company. But to not have a prototype means they squandered the money, since it clearly could have been done.

It's not impossible. My co-worker has produced, for far less than $500,000 a fully functional, 100% legit, electric-only vehicle. He uses it to commute to work, or at least he did, until he quit to pursue creating more with his new company. And oh by the way, he drives it on public roads because it's DMV certified. And it will also beat a porche at a drag race. Fun, eh?

http://evdrive.com/

If they couldn't turn $500k into a prototype, then they did not have the required skills to create the prototype in the first place.