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.
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.
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:
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.
The datasheet for the secure uC might never be released.
The datasheet is available under NDA, but will unfortunately not be available otherwise.
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:
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.
Their proprietary uC seems just yet another “Intel ME”
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.
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.
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.
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:
- The datasheet for the “secure uC” would need to be made public.
- All the firmware sources, including for the uC, NFC chips, and the BIOS, would need to be published.
- The toolchain for building all the firmware would need to be made available.
- The firmware build process would need to be made reproducible (perhaps it is already, we don’t know that).
- 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.
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.