With recent chipsets, Intel offers a mechanism called Active Management Technology (Intel AMT, part of the “vPro”* featureset, specifically the Intel Management Engine) which, Intel says,“allows IT or managed service providers to better discover, repair, and protect their networked computing assets”. This means somebody can control devices remotely, even when powered off—what is officially called out-of-band system access.
Yes. This is the case with recent hardware (post 2008) from mainstream computer manufacturers. It was created, not as some conspiracy of remote access to all hardware, but as a specific request from businesses and their technology departments to be able to remotely control large swaths of systems that they own, at a lower level than the operating system. In practice, it is essentially a “backdoor”.
You can imagine how that represents a serious security and privacy problem for everyone else.
The good news is: AMT remote access is not possible on Purism hardware.
Intel AMT requires three parts to work. The presence of these three parts is required to enable out-of-band remote access:
Our solution is thus:
So, we do use the “consumer” (smaller) version of the Intel Management Engine (Intel ME) binary, a choice that already provides some degree of protection (feature incompatibility) against Intel AMT, and then we take the extra precaution of neutralizing and disabling the ME itself (flipping off a hidden switch, then removing everything but the “hardware initialization” module) so that it is truly considered harmless for all practical purposes at this point.
The only (theoretical) piece of the puzzle left is to free that remaining portion, the (presumed harmless) hardware initialization module, which represents about 7% (120 kilobytes) of the Intel ME’s code.
No, none that we are aware of, nor have put-in. As it relates specifically to Intel AMT, we neutralize the threat by avoiding Intel CPUs that have the hardware chip allowing it, we do not use Intel networking cards, we use a version of the Intel ME that Intel claims does not have these capabilities (yes, we know that “Intel claims…” means we don’t have visibility into the source code, and yes, we know that is a concern, and yes, we are working on solving this), we disable the Intel ME using the HAP technique, and we neutralize/lobotomize the Intel ME binary, including the “network” and “kernel” parts of the Management Engine.
This is mostly out of philosophical and theoretical concern. We hope to go beyond “99.9% certainty”, we want to be “100% sure”, by knowing precisely what the remaining 7% of the Intel ME is doing (even though we’re pretty sure it’s harmless, considering we neutralized and disabled all the rest of the binary, including all the nasty bits). Therefore:
Remember: even if we didn’t neutralize the ME binary, our situation would still be an order of magnitude less worrysome than the enormous security hole that a complete Intel AMT system (with all three “puzzle pieces” put together) represents—a system vulnerable to all-encompassing remote access even when powered off.
The good news is, we actually do neutralize (and disable) it on our coreboot-enabled systems, so you can feel safe about using our products.
Purism is proud to select CPUs that do not have vPro or AMT chips on them, we are proud to use non-Intel wireless cards to avoid any potential conflict, we are happy to know we use a smaller consumer version of the Intel ME that Intel says cannot work to offer out-of-band remote access, and we are proud to say we take the extra step of further neutralizing the Intel ME.
Therefore, Purism actively avoids Intel Active Management Technology and has worked hard to improve the situation, being the first manufacturer of brand-new high-performance laptops to neutralize the threat of the proprietary Intel ME, with the future goal of continuing to free its initialization modules as well.