7 ms·

I bet you that the next generation of Intel processors will have patched this workaround from working, and maybe go as far removing the ability to kill IME unle

• amelius 9y ago
  Wouldn't it be possible to isolate the processor from the network interface? E.g. by using a network card that requires special access codes? I imagine you could build such network interface using an FPGA module.
  • openasocket 9y ago
    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.
    • amelius 9y ago
      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.
      • icegreentea2 9y ago
        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.
        • amelius 9y ago
          Hence my suggestion to build our own NIC using an FPGA board.
        • daxorid 9y ago
          > 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.
          • gruez 9y ago
            >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.
            • mschuster91 9y ago
              > 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.
            • daxorid 9y ago
              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.
    • julian_1 9y ago
      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.
    • tinus_hn 9y ago
      If the board supports PXE boot, the bios or UEFI can access the network. No magic required.
      • openasocket 9y ago
        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 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.
        • tinus_hn 9y ago
          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.
        • comatose 9y ago
          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
• laurentdc 9y ago
  I think they already did: https://github.com/corna/me_cleaner/wiki/Intel-Boot-Guard https://github.com/corna/me_cleaner/wiki/Intel-Boot-Guard
  • craftyguy 9y ago
    That has been around for years, and requires that the CPU + motherboard are paired during manufacturing so the CPU can be fused appropriately.
  • Kwastie 9y ago
    interestingly enough some implementations are broken because of buggy UEFI (AMI) https://embedi.com/blog/bypassing-intel-boot-guard https://embedi.com/blog/bypassing-intel-boot-guard
    • revelation 9y ago
      No surprise, I mean verifying the integrity of the BIOS is like PlayStation 1 level of crypto chainloading madness. A great scheme that will always fail because whatever software you are verifying will be imperfect. The chance that software produced by companies whose "day job" is putting flashing LEDs and DC-DC converter heatsinks on reference designs is zero.
• Chaebixi 9y ago
  > I bet you that the next generation of Intel processors will have patched this workaround from working, and maybe go as far removing the ability to kill IME unless you use some kind of rotating encryption dongle. Unfortunately for consumers, there's no way to escape this as even AMD has their own IME. What would be the justification for Intel going through all that trouble to do that (besides a conspiratorial "the NSA needs it to spy on everyone")? The impression I've gotten, to this point, is that Intel just doesn't care enough about people in the general public who are bothered by the IME to publicly support ways to disable it. Governments had enough buying-power to get Intel to implement an unsupported workaround, but I'm not convinced Intel has a motivation to make accessing that workaround hard.
  • kuschku 9y ago
    > What would be the justification for Intel going through all that trouble to do that (besides a conspiratorial "the NSA needs it to spy on everyone")? Well, some companies and users use the IME to enable theft-prevention technology. If you can circumvent the IME, you can easily steal a laptop and disable this theft-prevention technology. If that’s worth building an ever more closed walled garden is another question.
  • tree_of_item 9y ago
    > besides a conspiratorial "the NSA needs it to spy on everyone" Besides the real reason? I dunno.
    • Ajedi32 9y ago
      Do you have any specific evidence that the NSA is directly involved in pushing implementation of IME for the purposes of espionage? That's an extraordinary claim; the mere existence of the NSA isn't sufficient evidence that it's true. Yes, the NSA exists. Yes, it's their job to spy on people. And yes, it's perfectly valid to include mass surveillance in your threat model. But these constant, uncorroborated claims that the NSA boogeyman is hiding behind every rock and tree are starting to become quite tiresome.
      • 9y ago
• DannyB2 9y ago
  > . . . and maybe go as far removing the ability to kill IME unless you use some kind of rotating encryption dongle. Dear Intel, please PLEASE only use a solid state dongle with no moving parts! :-)
• kbenson 9y ago
  I'm pretty sure at this point what Intel has done is create a way to bypass everyones encryption schemes by hijacking the CPU, which might be prosecutable under DMCA anti-circumvention laws...
  • cyphar 9y ago
    Not sure that's correct. If you disable ME then DRM that depends on it just won't work. So it would be like saying that a power button is a DRM circumvention tool.
    • kbenson 9y ago
      I'm saying that the ME, by nature of the access to the CPU, memory and IO that it has, is likely capably of circumventing almost all software encryption run on the CPU through surreptitious gathering of information as the system runs encryption/decryption routines. Whether Intel intended to or not, they've built the mother of all circumvention tools, and circumvention is specifically not allowed in the DMCA.
      • cyphar 9y ago
        Intel ME is used as a component of DRM (see PAVP), which is what I was referring to. But this is quite an odd argument, by that definition your CPU would be a circumvention measure. And while you can use a CPU to circumvent DRM, just having a CPU isn't enough. Also, a normal user of a computer cannot do whatever they like with Intel ME, so its the least useful circumvention measure I've ever heard of. GDB is infinitely better. Not to mention that most DRM depends on the encryption being done outside of the computer's CPU. HDMI's DRM relies on the local computer not being aware of the contents of the stream and the monitor itself does the decryption with burned-in keys.
  • cl289 9y ago
    If I were in charge of collecting encrypted data at the NSA, I would make sure that whatever keys were used by the CPU's AES instruction set would be copied and saved using the CPU firmware. Then that data could be sent out with the ME, or simply stored in case that computer was ever an object of interest. In that way, anything encrypted (using hardware) could be decrypted. Seems like it would be malpractice by the NSA not to collect AES keys at the hardware level.
• leggomylibro 9y ago
  Not yet, but does SiFive's RISCV offerings have any sort of 'management engine'? If ARM continues to supplant x86, and an open ISA like RISCV starts to nip at ARM's heels...
  • monocasa 9y ago
    Sort of? They do have a simpler core off to the side for SoC management on their newer 64bit design. You're going to be hard pressed to find a moderately complex SoC without something like that. At a bare minimum, reset and power state sequencing is complex enough to offload to a microcontroller style core these days. The iMX6 is the biggest, most reent SoC I an think of without that.