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.
What?! Remote access even when powered off?
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.
How does Purism avoid Intel’s AMT?
Intel AMT requires three parts to work. The presence of these three parts is required to enable out-of-band remote access:
- an Intel CPU that supports the vPro feature set;
- an Intel networking card;
- the corporate version of the Intel Management Engine (Intel ME) binary.
Our solution is thus:
- We choose Intel CPUs that do not have vPro (nor AMT). Note that this does not mean that we are confined to using old/pre-2008 CPUs, however: we provide brand new, high-performance and feature-packed CPUs as part of our products, thanks to our sourcing, manufacturing and assembly operations. In practice, our CPUs and chipsets are just as cutting-edge as what you would find elsewhere (for example, we are shipping Skylake/6th gen Intel CPUs in 2017 and will be moving to Kaby Lake/7th gen within that same year).
- We do not use an Intel networking card (we use completely different network chipsets instead).
- We do not use the “corporate” version of the Intel Management Engine (Intel ME) binary.
- On coreboot-enabled Purism devices, we further neutralize and disable the Intel ME binary (see our Intel ME explanation page for details and status reports), with the intention of reverse-engineering the remaining parts (which we have already begun). Please note: the coreboot port to all existing Purism devices, as well as the reverse engineering work, is work-in-progress as of Q2 2017; the results of this work can be applied retroactively to customers’ existing systems with a simple software update.
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.
So, there is no hardware level remote access to Purism hardware?
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.
You’re still working on freeing the remainder of the “consumer” Intel ME version used on Purism hardware. Why?
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:
- We released a petition for, and continue to work with Intel to free it entirely (what Intel is calling a “ME-less” design).
- We are also planning to reverse-engineer the remaining parts. We have reverse-engineered the ROMP module and will continue the work for other modules throughout 2017.
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.