Recently, Joanna Rutkowska, the founder of Qubes OS (which we announced as a default OS option), posted on her Invisible Things blog and on Twitter some of her thoughts on ORWL. We offer here our comments and responses to specific points, as well as a more general response. Some of what is described in this update is laid out in our previous update on secure microcontroller (MCU) details.

Auditability of the Mainboard Secure MCU

As an interpretation of our use of the mainboard secure MCU, Joanna writes:

Our proprietary, impossible-to-audit, running nobody-knows-what firmware microcontroller (uC) has full authority over the boot process and execution of any system and apps running on our ORWL computer.

and:

All the user data can be recovered by whoever has/finds a way to retrieve the key from our impossible-to-audit, impossible-to-verify uC.

There’s a lot to unpack here:

• The secure MCU is proprietary to Maxim, just as nearly every integrated circuit (IC) is proprietary to its manufacturer - very few ICs are what anyone would call open.
• As detailed in an earlier campaign update, the secure MCU is auditable so long as the auditor enters a NDA with Maxim. Far from ideal, but not impossible-to-audit.
• The question of what firmware is running on the secure MCU is one we’ve asked ourselves. Certainly, anything we write, we’ll make public, but there is a good bit of firmware we didn’t write. As it turns out, there’s the possibility of getting a custom secure MCU. We are still looking into this and will post a separate update once we learn more.
• The secure MCU has full authority over the BIOS of the Intel subsystem. By the same token, there is no way to rewrite the BIOS without the secure MCU knowing about it.

Licensing

As an interpretation of our claims about licensing, Joanna writes:

At some point in time, we will make select portions of the firmware (i.e. these portions we have authored, such as maybe the logo-displaying code) available… to select partners… using yet-to-be-determined licenses.

There are two issues here: what exactly will be licensed and what those licenses will be. To be honest, we’re still working on both those issues and aim soon to have a more extensive update about them. What we do know is that the firmware we release will include a port of Coreboot, which is a good bit more than the logo-displaying code. To be fair, we only announced this after Joanna’s blog post.

Secure MCU Datasheet

Joanna writes:

The datasheet for the secure uC might never be released.

The datasheet is available under NDA, but will unfortunately not be available otherwise.

Verification of Secure MCU Firmware

In response to the firmware verification process, Joanna writes:

"Dear uC firmware, can you tell me if you’re a good or bad one? Just please, please, be honest, ok?"

Verifying the firmware run on the mainboard secure MCU is possible with the following steps:

• Enter into an NDA with Maxim to obtain the toolchain for debugging and programming the secure MCU.
• Write custom code to dump the contents of the secure MCU’s boot image (provided by Maxim and stored in ROM) and firmware (provided by us and stored in flash).
• Sign the custom code using the unique key that comes with the secure MCU, or the key with which you’ve reprogrammed the secure MCU. The secure MCU will only run signed code.
• Load the signed code into the secure MCU’s RAM and dump the ROM and flash contents for examination.

Of course, short of doing a transistor-level analysis of every integrated circuit you use, you will need to at some point trust that the hardware is what it says it is.

Another Management Engine

Joanna writes:

Their proprietary uC seems just yet another "Intel ME"

and:

This ORWL’s proprietary uC is not going to alleviate the problems created by Intel ME in any way. Instead it will only add another ME-like device, controlled by another player. In other words: another actor(s) to worry about.

As far as we know, there is no datasheet for the Intel Management Engine (ME), even under NDA. That’s quite different than the situation with the secure MCU. In fact, the secure MCU actually mitigates some of the concerns around the Intel ME by controlling power to the Intel subsystem, thus guaranteeing the Intel ME is inactive when the Intel subsystem is shutdown. In short, the secure MCU helps reign in the Intel ME and is not nearly as opaque as the Intel ME. In this case, more actors means better behavior all around.

Relay Attacks

Joanna writes:

Still, one can ask: Is this physical mesh protection really worth the effort? It might seem so at first sight. But with such a small device that costs only a few hundred dollars, another physical attack seems to be no less of a problem: the relay attack.

and:

Can ORWL provide reasonable protection against such relay attacks? Maybe. But for some reason they do not boast about it on their page, where they discuss some other attacks they attempt to address.

Indeed, we’d forgotten to include this in our initial list of attacks. We’ve corrected this omission by adding a section on how ORWL mitigates relay attacks — we use time-of-flight measurements to detect relay attacks and rotating keys to foil them outright.

Minimum Requirements

Joanna writes:

Admittedly, though, the ORWL proposed physical security mechanisms, such as the board protection mesh, do indeed look interesting and potentially useful. Is there a way, then, to somehow "rescue" the ORWL device in order to benefit from these technologies? Perhaps, but as an absolute minimum, the following requirements would need to be met first:

1. The datasheet for the "secure uC" would need to be made public.
2. All the firmware sources, including for the uC, NFC chips, and the BIOS, would need to be published.
3. The toolchain for building all the firmware would need to be made available.
4. The firmware build process would need to be made reproducible (perhaps it is already, we don't know that).
5. The uC should expose a reliable way to dump the whole firmware through some h/w mechanism, such as a JTAG port, or at the very least allow for a reliable flashing of a new one.

We agree and believe we can meet all these requirements, with the caveat that the secure MCU datasheet is available under NDA. Regarding the toolchain and firmware, we will soon announce a “dev kit“ pledge level that contains tools to build and verify all firmware from start to finish.

Something vs Nothing

We believe doing something with what you have is better than doing nothing until the universe presents you with the perfect conditions. Joanna’s work on Qubes OS exemplifies not letting the perfect be the enemy of the good - coexisting with the Intel Management Engine is not ideal, but it is better than doing nothing. In the same vein, we created ORWL to advance the state of the art in physical security for personal computing. ORWL is not perfect, but we believe it’s a quantum leap forward and much better than anything that currently exists. Furthermore, ORWL will lead to even better options down the road. In the meantime, we will continue to document, share, and expand upon our findings. Please get in touch with any questions or comments.