Intels AES-NI instructions
-
I'm not going to mention "side channel attacks" because i have simply watched a related slideshow. I feel there are undocumented registers that could be flashed with a microcode update and you would never know. They probably ship from factory good but get injected later.
Where i would like to have seen the debate turn is whether CPU based implementations of speed enhancements of crypto with its possible -security issues- are worth the trade off for security of something that can be analyzed at length(software code). AES in software versus AES-NI. I know all about yarrow, i am just talking is this speed boost worth it for the security risk? Even in mom and pop shops with "Nothing to hide"… Everybody here seems hip to AES-NI it but i don't see any naysayer's...Am i just a paranoid loon?
-
This gives me no warm fuzzy feels either
http://www.theregister.co.uk/2015/02/17/kaspersky_labs_equation_group
America's National Security Agency (NSA) has infected hard disk firmware with spyware in a campaign valued as highly as Stuxnet and dating back at least 14 years, and possibly up to two decades, according to an analysis by Kaspersky labs and subsequent reports.
The campaign infected possibly tens of thousands of computers in telecommunications providers, governments, militaries, utilities, and mass media organisations among others in more than 30 countries.
The agency is said to have compromised hard drive firmware for more than a dozen top brands, including Seagate, Western Digital, IBM, Toshiba, Samsung and Maxtor, Kaspersky researchers revealed.]/quote]
-
Well I guess if I'm going call being jacked by intel iJacked then firmware hijacking in general should be fJacking.
-
@Phishfry:
I'm not going to mention "side channel attacks" because i have simply watched a related slideshow. I feel there are undocumented registers that could be flashed with a microcode update and you would never know. They probably ship from factory good but get injected later.
Where i would like to have seen the debate turn is whether CPU based implementations of speed enhancements of crypto with its possible -security issues- are worth the trade off for security of something that can be analyzed at length(software code). AES in software versus AES-NI. I know all about yarrow, i am just talking is this speed boost worth it for the security risk? Even in mom and pop shops with "Nothing to hide"… Everybody here seems hip to AES-NI it but i don't see any naysayer's...Am i just a paranoid loon?
My rule of thumb is if the government comes knocking on my door, I'm going to gladly give them my keys. I am more concerned about malware or a laptop getting stolen.
-
The problem with back-doors is that they don't stay secret, having NSA peeking at my system is less worrying than having some guy in Bulgaria that found the back-door shopping my information to his buddies.
-
The most concerning exploit I can think of is the RNG. Almost any changes to AES-NI will cause the system to stop working and will be easily detectable as storage and network instantly breaks. But changes to RNG does not cause catastrophic failure.
Most any back door related to AES-NI will probably require physical access at some point. AES-NI could save the last N keys in non-volatile on-chip storage or at a certain memory location in dram. Storing unexpected data in dram could very likely result in data corruption unless the location was reserved, but the CPU does not reserve memory, it would have to be in concert with another device that is also back-doored.
Most of the end result either involve physical access or your system crashes. My guess is a back-door that causes a system to crash would be not desirable because people would start digging, so that severely limits the types of back-doors.
Any hardware based remote backdoor would require several devices to work together to accomplish this feat. Doing this transparently in a way that doesn't cause an OS to crash would be quite hard, since not all OSs work the same and they change over time.
-
"My rule of thumb is if the government comes knocking on my door, I'm going to gladly give them my keys. I am more concerned about malware or a laptop getting stolen"
Congratulations - If enough of us start thinking that way, North Korea will start looking like a good vacationing spot.
-
I guess I could let them beat it out of me, but I'm not sure I want broken fingers just to protect my anime collection.
-
I'd let them beat it out of me and then laugh when they find my my music collection.
I think wasting their time and effort on a mass scale is in fact the best way to discourage such endeavors.
Basically, I would like everyone to look as "suspicious" as possible. IE. Encrypt everything. -
I guess I could let them beat it out of me, but I'm not sure I want broken fingers just to protect my anime collection.
May your chains set lightly upon you.
-
@Phishfry:
I'm not going to mention "side channel attacks" because i have simply watched a related slideshow. I feel there are undocumented registers that could be flashed with a microcode update and you would never know. They probably ship from factory good but get injected later.
Why get that complicated? If an attacker is in a position to flash a microcode update (which basically means they flashed a modified BIOS), surely they can scrape memory and get your key that way, right?
@Phishfry:
Where i would like to have seen the debate turn is whether CPU based implementations of speed enhancements of crypto with its possible -security issues- are worth the trade off for security of something that can be analyzed at length(software code). AES in software versus AES-NI. I know all about yarrow, i am just talking is this speed boost worth it for the security risk? Even in mom and pop shops with "Nothing to hide"… Everybody here seems hip to AES-NI it but i don't see any naysayer's...
What's the security risk you're worried about? Keep in mind AES-NI isn't at all like a hardware security module- it's just an accelerator. Your encryption keys are still managed by software, accessed from memory, and (likely) stored on disk. I'm struggling to think of a plausible attack that would be better done by injecting malware on the CPU rather than just a rootkit that scrapes your keys from memory. The latter is much, much easier.
I'll note AES-NI has at least one distinct security advantage: it's non-trivial to write a software AES implementation that's resistant to cache timing side channel attacks.
@Phishfry:
Am i just a paranoid loon?
Probably. Not that that's a bad thing.
-
The most concerning exploit I can think of is the RNG. Almost any changes to AES-NI will cause the system to stop working and will be easily detectable as storage and network instantly breaks. But changes to RNG does not cause catastrophic failure.
Agreed. To make matters worse, poor RNGs are extremely difficult to detect. And in crypto protocols there are lots of opportunities for the attacker reconstruct the state of your RNG if it has a major weakness.
Most any back door related to AES-NI will probably require physical access at some point. AES-NI could save the last N keys in non-volatile on-chip storage or at a certain memory location in dram. Storing unexpected data in dram could very likely result in data corruption unless the location was reserved, but the CPU does not reserve memory, it would have to be in concert with another device that is also back-doored.
Maybe I'm not following you, but AES-NI doesn't do what you think it does. As I said in my previous post, AES-NI is just an accelerator. If you want to steal a key, you certainly don't need physical access. The keys are just sitting in memory, so you just need to memory-scrape it (or, in some cases, read it from disk).
Even if someone wanted to put a backdoor in AES-NI, I'm not even sure what they'd do that wouldn't be better accomplished with some other form of malware. (And those other methods would work perfectly fine against any software crypto library.)
Any hardware based remote backdoor would require several devices to work together to accomplish this feat. Doing this transparently in a way that doesn't cause an OS to crash would be quite hard, since not all OSs work the same and they change over time.
Well, that depends on what you mean by a hardware-based backdoor. Purely hardware? Sure, that looks needlessly complicated. But if that includes tampering with low-level firmware, either in the BIOS or in the firmware in any of the numerous devices in your computer with direct memory access, then that doesn't look that hard. It seems like an awful lot of work to for a highly targeted attack, though.
-
The more i think about my argument the more i realize it does not add up. If anyone had the ability to flash the microcode of your cpu they would probably go after something easier than AES-NI….
I do find it odd that Cavium crypto accelerators and their binary blob and NDA are banned but the intel cpu AES-NI is different how???
-
@Phishfry:
The more i think about my argument the more i realize it does not add up. If anyone had the ability to flash the microcode of your cpu they would probably go after something easier than AES-NI….
More than that, if someone had the ability to flash microcode, they'd probably go after something easier and likely more powerful than microcode: SMI handlers.
Or just rootkit the kernel. That's a lot easier and probably would still do 99% of what they'd want. But I'm happy to feed your paranoia with more sophisticated attacks.
-
Your not bugging me the least.
As Thomas J would say:
"A Well-Informed Populace Is Vital To The Operation Of A Democracy"I find it ironic the press is acting like a harddrive firmware hack is a first. The assembly of 12 drive manufacturers virus tools -Now that is impressive(If i didn't have to pay for it!)
I don't see any Compact Flash manufacturers on the list(small reprive).
-
The most concerning exploit I can think of is the RNG. Almost any changes to AES-NI will cause the system to stop working and will be easily detectable as storage and network instantly breaks. But changes to RNG does not cause catastrophic failure.
Agreed. To make matters worse, poor RNGs are extremely difficult to detect. And in crypto protocols there are lots of opportunities for the attacker reconstruct the state of your RNG if it has a major weakness.
Most any back door related to AES-NI will probably require physical access at some point. AES-NI could save the last N keys in non-volatile on-chip storage or at a certain memory location in dram. Storing unexpected data in dram could very likely result in data corruption unless the location was reserved, but the CPU does not reserve memory, it would have to be in concert with another device that is also back-doored.
Maybe I'm not following you, but AES-NI doesn't do what you think it does. As I said in my previous post, AES-NI is just an accelerator. If you want to steal a key, you certainly don't need physical access. The keys are just sitting in memory, so you just need to memory-scrape it (or, in some cases, read it from disk).
Even if someone wanted to put a backdoor in AES-NI, I'm not even sure what they'd do that wouldn't be better accomplished with some other form of malware. (And those other methods would work perfectly fine against any software crypto library.)
Any hardware based remote backdoor would require several devices to work together to accomplish this feat. Doing this transparently in a way that doesn't cause an OS to crash would be quite hard, since not all OSs work the same and they change over time.
Well, that depends on what you mean by a hardware-based backdoor. Purely hardware? Sure, that looks needlessly complicated. But if that includes tampering with low-level firmware, either in the BIOS or in the firmware in any of the numerous devices in your computer with direct memory access, then that doesn't look that hard. It seems like an awful lot of work to for a highly targeted attack, though.
For both the AES-NI and "hardware" backdoors, I was going after is it would be hard to create remote backdoor that was integrated into the hardware and not software. Creating any old remote backdoor wouldn't be hard, but creating an undetectable backdoor that does not crash the system would be quite difficult if it was built directly into the CPU or network silicon.
I assume the easiest place would be into the drivers, assuming they're binary blobs.
