It already can't communicate with a non-Intel network card IIRC. It would need some kind of driver, and it's not like it can use the OS' network card driver, unless the IME is automagically able to use Windows, OSX, and Linux drivers.

Are you sure? I suppose any network card on the PCI bus can be accessed by the CPU in principle. And leave it to the people of the NSA to install clever software in the IME module that doesn't disrupt the OS's communication with the network card.

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.

If the board supports PXE boot, the bios or UEFI can access the network. No magic required.

Hmmm, this stumped me for a while. Your argument makes complete sense, but then why do I need drivers for my OS to access the NIC, when it should be able to use the same API exposed to BIOS? So I looked it up: https://en.wikipedia.org/wiki/Preboot_Execution_Environment

It's fairly light on details, but my interpretation is that for a NIC to support PXE boot it has to have firmware that exposes a standardized API so that the boot loader can functions as a DHCP client and a TFTP client. As far as I can tell, the NIC doesn't have to provide some standardized method for general access, just those two things. The NIC could even have a completely different, completely separate API that it expects the OS to use, and just has some firmware that acts as a shim to expose to the boot loader the PXE client API.

Assuming this is true, Intel ME could access the NIC using the PXE boot API, but this only gives it the ability to act as a DHCP client and TFTP client, not arbitrary networking operations.

I could be completely wrong about that, though. This is, at best, an educated guess.

The bios and uefi obviously can also access the hard disk, otherwise you can’t boot. The OS still has its own driver though. That’s because (at least the BIOS version) is optimized for a small code size and a limited environment, while in the OS you want speed and features.

pxe booting loads a lightweight os, ime can access the networking later when the full os is loaded but has generic or specific drivers for low level net access. ime doesn't use pxe though, afaik

The thing is running Minix OS, so it's not inconceivable to configure non-intrusive drivers for third-party NICs sitting on the pci bus.