Comment by asuffield | Hacker News Reader

Comment by asuffield | Hacker News Reader

It's an interesting idea, but probably hopeless: all this does is move the goalposts. You're still fundamentally trusting the hardware to read and obey the instructions on your weird "external SPI" device, and if you're willing to trust the hardware then you might as well just put it on the motherboard like today's devices do. If you don't trust your hardware (and I challenge anybody to prove that a motherboard full of chips hasn't had a chunk of flash memory added to it without your knowledge) then you have no reason to think that the code it loaded was the code stored on your "trusted stick".

I don't believe that it is possible to build a secure system which isn't based on trusting the device that you hold in your hands. At some level, you need to have a device which is capable of both UI and computation functions to a sufficient extent to validate whatever transaction you are attempting to sign. You could push that onto a smaller device than your laptop (we already know that phone-sized devices are viable), but you still have to end up at the thing you interact with for signing purposes being a device that you trust.

Moving the bar from "This machine can be subverted by anybody who can access the SPI bus" to "This machine can be subverted by anybody who can solder on additional hardware that intercepts and modified bus activity" is still significant.

I don't think soldering's really required. If I was attacking the proposed system, I'd just jam a variation on those nifty miniature usb keyloggers into the path of the usb port itself. If somebody was building devices like this, then somebody else would quickly create such a device that could be quickly slipped into place (possibly even one you could just jam into the usb port without opening the case, like the fake slots that ATM hacks use).

(Or rootkit the "trusted" usb stick)

What would that get you? The input devices are almost certainly going to be internal and PS/2 or I2C, and if you're the sort of person doing this you'd be using encrypted storage.

I mean tapping the external SPI connection at that point. You can't encrypt the first stage that gets loaded into the CPU, so you would simply replace that with your rootkit and then continue as normal until the user types the decryption key into the now-compromised device.

The CPU measures the first block of the firmware into the TPM. This is already a solved problem.

I'm fascinated by the idea of having a TPM without any on-board storage for it to use. How do you propose that would work?

If you're willing to accept stateful storage for the TPM then I agree this is straightforward, but then I don't think the "stateless device" has been achieved. If you're willing to trust the TPM's storage then you could have just used that to establish trust for everything (which is the status quo on chromebooks).

As described in the article, PTT includes a TPM running on the ME. The CPU loads the ME firmware (which is validated against a key on the ME), then starts executing the rest of the firmware (including copying measurements to the TPM).

So it just boils down to TPM-protected encrypted storage? That obviously works (because it's how a bunch of devices work today), but it's a lot less exciting... if you can set up a full TPM stack for sealed storage (which we don't have on consumer linux today :( ) then I don't see what attacks this "stateless laptop" defends you against that the TPM doesn't already handle.

I think the main point is that if you trust the main board once, you can trust it (more) in the future. If it doesn't have any changeable memory, modifying it to become hostile is harder and requires physical tampering.

As Animats said, solving that problem just requires making the firmware read-only at the chip level. Which is cheap. The current problem exists so devices can be easily updated and contain more features. Users demand both with both benefiting hardware market. A a ROM + Flash setup solves the problem but adds a little to cost. Most companies won't do it but it's another viable solution.

It is going to be pretty hard to take an off-the-shelf notebook and make the proposed changes, especially when you are talking about implementing hardware kill switches for certain components on a 12 layer PCB. The strongest incarnation of this idea seems to involve cooperation with, and some degree of trust in, the motherboard manufacturer (whether that is Purism or someone else). Is there any solution to nation-state hardware attacks involving intercepting your notebook while it is being delivered to you? I think that has always been considered "game over" as far as maintaining security.

However, if you have that, you do get a significant benefit. You are no longer vulnerable to someone sticking a rootkit in your BIOS. That is where a lot of the up-and-coming SMM-level rootkits like to be installed. You can move a fair chunk of your root of trust (the firmware, etc) into a device separate from the notebook, and feel pretty comfortable that device is going to provide certain guarantees about flash memory contents that we do not have with today's systems.

IMO, the ability to run multiple truely independent operating systems on the same hardware (if nothing else) makes it worthwile.

I am not convinced that forcing attacks to be more likely to be detected is really much of a deterrent in a world where Lenovo can pre-install a rootkit in the bios and not suffer all that much from it. I still think there are overall benefits to aiming for a stateless system.

This is pretty much what the Raspberry Pi does, so we should all switch to that :-)

There is ROM (as far as we know) in the GPU which instructs it to read the CPU firmware from the SD card, and then boots up the machine. Unfortunately neither firmware is open source or well documented, so you still can't really trust it.

This circumvention of surveillance could work for current processors that assume they can trust the SPI chip. But it would be easy for Intel to package the SPI chip together with the CPU in future offerings, circumventing the circumvention.

I don't see any assurance for anyone that doesn't control the foundry itself.

Yes, Intel might do that, but "circumventing the circumvention" is practically describing Intel making the change as some kind of malicious/hostile actor that wants to facilitate you being the victim of a BIOS hack. I don't think that is what is happening, but the current architecture does have undesirable consequences. Rotkowska's proposal doesn't really "circumvent" anything Intel is doing - it mainly allows the end user to assert a clean BIOS state.

Reply on news.ycombinator.com