Known attacks and their response

Cold boot

Cold boot attacks consist in removing the DRAM or power-cycling the machine in order to read the memory content. The DRAM is often chilled to slow down the loss of information that occurs when the cells stop being refreshed.

Mitigations: The DRAM is soldered, and protected by the security mesh. Cooling down the secure microcontroller will trigger a tamper event, key erasure and system power down. Encryption keys are only stored in the main memory by the UEFI for an extremely short time before they are passed to the SED, and are securely memset’ed long before the OS is booted. When the machine is put in sleep mode while the user is away, the key is not stored in the main memory nor in the SED controller memory. The entire RAM is wiped before the OS is booted, to prevent other kinds of attacks on the memory content.


UEFI BIOS, SMM attacks, and all sorts of platform vulnerabilities allow an attacker to run very privileged code that is both invisible to the OS and capable of achieving persistence by modifying the SPI flash. The UEFI image can also be modified by physical access to the component.

Mitigations: We are in direct contact with the UEFI vendor and will work on patching public vulnerabilities. In the event that an attacker is able to exploit an SMM, UEFI or platform vulnerability, there is no vector for persistence. The SPI flash Write Protection is controlled by the secure microcontroller, and the update process can be tied to a specific keyfob or pin. The SPI flash content is also verified at every boot, before the Intel subsystem even receives power. Finally the external verification process allows you to easily read the flash and verify it.


External DMA attacks over PCIe or Firewire can allow an attacker to read the memory content while the machine is running.

Mitigations: We do not expose DMA-capable ports externally. For internal ports, the SED we selected is not PCIe capable. The Intel processor also supports VT-d, allowing you to block this class of attacks from software.


The device is intercepted during shipping, modified, then forwarded to its destination.

Mitigations: The system PIN is will be shipped under separate cover, as is the case for your credit card or debit card PIN. If the device is opened for tampering prior to arrival, the Root of Trust is deleted. Replacing this requires a paired keyfob and the PIN. The result is that the owner will not be able to successfully boot the device if it’s been tampered in this way. Because you have visibility on firmwares, most software implants are very risky to use for your attackers. The hardware is protected by the shield, and the OLED screen that is the only exposed component is protected by a dedicated mesh. The screen Flexible Flat Cable has a mesh on both sides, and is just a long as required. The space between the glass enclosure and the shield is also minimized.

External firmware verification process

The verification process is driven by the Secure Microcontroller. Its boot rom allows it to load and execute code in RAM directly by sending commands on a UART port. This UART port is routed to the Side-Band Use (SBU) pins of one USB-C connector, so the verification can be made quickly and as often as required without any disassembly.

We will provide a minimal open-source applet, capable of hashing and extracting most of the firmwares on the machine:

  • The entire Intel subsystem SPI flash including UEFI, external ME firmware, etc.
  • The ARM-Thumb PMIC firmware (Power Management IC) stored on a dedicated W25Q40 SPI flash.
  • The secure microcontroller firmware.

Using SHA512 accelerators, we are aiming at less than 300 single lines of code for the applet. The ARM assembly generated from the C code will also be thoroughly audited before it is published.

The main missing firmware is the M.2 SSD controller. This is an unsolvable problem, as no firmware verifiability is provided by vendors (quite the contrary) and the M.2 connector is constraining the interface. Fortunately, this component can be changed so you can replace it if you think it has been compromised, and you can pick a brand you trust or have JTAG access on.

Internal firmware verification process

Because traditional TPM-based secure boot is very complex and relies on a chain of software behaving correctly, we designed an independent solution, simple and powerful, for verifying the integrity of most of the platform firmwares (including external components like the PMIC, something a TPM cannot help with). The TPM is still there, and both methods happily work together. The secure microcontroller will hash and verify the firmwares before the Intel subsystem is even powered on, making it very difficult for an attacker to modify the BIOS in any way without you knowing.

We will not ship machines with Boot Guard “Verified Mode” activated, meaning that if you choose to disable our firmware verification mechanism, or you add your own signing keys, you will be able to develop and run an alternative BIOS, like Coreboot. In fact, we have engaged a company (Eltan) to work with us on porting Coreboot onto the platform. This version will include at least one opaque “binary blob” from Intel, but we’ve seen references to people being able to work around this piece, and such a modified Coreboot implementation can be created and used by the community.

ORWL usage and access control