Hacker News new | past | comments | ask | show | jobs | submit login

So I guess it comes down to what you think the point of the ME is. If its for what Intel claims, then having the ME have to access the NIC through the OS is useless - the whole point is to bypass the OS, so you can manipulate the computer regardless of its state (as long as its plugged in anyways).

If you were worried about NSA spyware that tunnels through your OS... well, then you may as well just be worried about NSA spyware in your NIC.

Because in the end, even if the ME was directly connected to the NIC, it still needs to know how to talk to the NIC (thus why NICs have drivers...). When you use an Intel NIC, the ME knows how to talk to it, and everything is hunky dorey. In practice, Intel could probably build a database of common non-Intel NICs and load all of their drivers into the ME. But really, if we assume that the ME exists for business reasons, then its obvious why Intel will just keep it all as Intel. They are nominally selling something that is advantageous to large organizations, and would like said large organizations to buy as much Intel gear as possible. Said large organizations believe that ME provides sufficient value to go with Intel NICs instead of other NICs.




> If its for what Intel claims

If it's for what Intel claims, then they would trivially offer an option for the customer to disable it. Hell, they could even make it a selling point for higher-margin chips like Xeon.

Does ME have business purposes? Sure. But their staunch refusal to allow disabling by nongovernmental customers does not pass the sniff test. There is clearly some other, non-business reason for it.

> then you may as well just be worried about NSA spyware in your NIC

If you own my NIC but not my CPU, I can encrypt my traffic and blind you.

If you own my CPU (especially my AES-NI ISA), my options are more limited. Much higher-value target.


>If you own my CPU (especially my AES-NI ISA), my options are more limited. Much higher-value target.

>especially my AES-NI ISA

why aes cpus specifically? you're free to not use aes instructions. besides, if you own the cpu, you load whatever shellcode you want, no need to backdoor the aes instruction.


> you're free to not use aes instructions.

good luck getting a system compiled that does not use them at all. Might be possible with gentoo and the right configuration as it compiles everything, but with a dominantly binary distro like Ubuntu or Debian you're SOL.


Especially, not specifically.

I was just saying my options are more limited, and the options for someone unwilling to recompile their own software is very severely limited.

But even if I'm running, say, software-only Salsa20 with all compiler optimizations off, if my CPU is still owned, my keys are still at risk of silent compromise.

The only real defense is to ascertain the processing limitations of IME and then choose your crypto primitives/implementation for both processing and memory hardness that exceeds the ability of the IME's lower transistor count and/or clock speed to keep up with.


How about a foreign (to the US) power? Imagine the kind of damage they could do if they were sitting on a 0-day. North Korea, for example, could steal financial data to fund their nuclear program, or manipulate critical infrastructure. As a system designer, I'd want to mitigate that kind of threat, and I don't know if I have the knobs and switches available to me to do that with this design.


Hence my suggestion to build our own NIC using an FPGA board.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: