4 ms·

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 inst

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.

detaro 11y ago
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.
- nickpsecurity 11y ago
  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.
candeira 11y ago
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.
- rolandr 11y ago
  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.
mjg59 11y ago
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.
- asuffield 11y ago
  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)
  - mjg59 11y ago
    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.
    - asuffield 11y ago
      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.
      - mjg59 11y ago
        The CPU measures the first block of the firmware into the TPM. This is already a solved problem.
        asuffield 11y ago
        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).
rolandr 11y ago
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.
joveian 11y ago
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.
lucaspiller 11y ago
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.

detaro 11y ago

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.

nickpsecurity 11y ago
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.

candeira 11y ago

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.

rolandr 11y ago
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.

mjg59 11y ago

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.

asuffield 11y ago
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)
- mjg59 11y ago
  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.
  - asuffield 11y ago
    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.
    - mjg59 11y ago
      The CPU measures the first block of the firmware into the TPM. This is already a solved problem.
      - asuffield 11y ago
        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).

rolandr 11y ago

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.

joveian 11y ago

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.

lucaspiller 11y ago

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.