4 ms·

Neither remote attestation, decompilation of firmware blobs, reading the chip specification nor IOMMU are universal solutions to all security problems. They do

by kfreds 3y ago

Neither remote attestation, decompilation of firmware blobs, reading the chip specification nor IOMMU are universal solutions to all security problems. They do however complement each other nicely. Imagine connecting to a Jitsi or Etherpad service over HTTPS - all you get is some assurance that the remote system is operated by the owner of a specific DNS name. Now imagine the same situation, but you also have a browser extension that verifies that the boot chain of the remote system is reproducible and discoverable in a transparency log. As I mentioned elsewhere in this thread, System Transparency aims to make the reachable state space of a remote system discoverable. Imagine your web browser being able to verify whether you're connecting to a Jitsi server, or a Jitsi server which also records all meetings. You're absolutely right that there are lots of limitations and things that can't be mathematically proven, but that goes for any defensive security technology. For sure remote attestation can be used against the interests of the user, but it can also very much be used for the interests of the user. Imagine a world where you don't have to trust online services blindly.

rollcat 3y ago
> Imagine a world where you don't have to trust online services blindly. Most online services can be hardly trusted to use TLS between the frontend web servers and the database, or not to store sensitive credentials in git. These are: 1. far more serious issues than a trusted boot chain, 2. far easier to address, and 3. disproportionately more difficult to remotely attest. Transparency would definitely help here as well, but transparency is an aspect of company culture, and presently so dominantly opt-in that unless we see some fundamental cultural shift, this will be an extremely niche feature to expect from a service provider. > They do however complement each other nicely. Yes I do agree, and I do believe that security is more about breadth than depth - raise the wall evenly around the fortress, so that no part of it is less tall than X. That does often require investment in hardware, but I think there is much more to gain e.g. by streamlining setting up FDE with interactive key input from initrd+dropbear, something I've always wanted to set up on my boxes but something that's too painful/tricky/brittle to do at medium scale (too many servers to do it by hand, not enough to invest in in-house automation).
- kfreds 3y ago
  You're absolutely right that almost all organizations have lower-hanging fruit to worry about than remote attestation, reproducible builds and transparency logging with distributed trust assumptions. Nor do they spend three years designing said transparency log. Nor do they care about their USB authenticators being open-source hardware that uses a measured boot KDF instead of the verified boot approach. Nor do they design those devices using open-source tooling (Kicad, Yosys) or spend time and money reversing the NVCM programming and locking feature so they can lock their FPGAs using open-source tooling. But my companies do. We endeavour to advance the state-of-the-art in trustworthy computing, similarly to how my first company (Mullvad VPN) advances the state-of-the-art of what a privacy-focused VPN service should do. :)

by kfreds 3y ago

rollcat 3y ago

> Imagine a world where you don't have to trust online services blindly. Most online services can be hardly trusted to use TLS between the frontend web servers and the database, or not to store sensitive credentials in git. These are: 1. far more serious issues than a trusted boot chain, 2. far easier to address, and 3. disproportionately more difficult to remotely attest. Transparency would definitely help here as well, but transparency is an aspect of company culture, and presently so dominantly opt-in that unless we see some fundamental cultural shift, this will be an extremely niche feature to expect from a service provider. > They do however complement each other nicely. Yes I do agree, and I do believe that security is more about breadth than depth - raise the wall evenly around the fortress, so that no part of it is less tall than X. That does often require investment in hardware, but I think there is much more to gain e.g. by streamlining setting up FDE with interactive key input from initrd+dropbear, something I've always wanted to set up on my boxes but something that's too painful/tricky/brittle to do at medium scale (too many servers to do it by hand, not enough to invest in in-house automation).

kfreds 3y ago
You're absolutely right that almost all organizations have lower-hanging fruit to worry about than remote attestation, reproducible builds and transparency logging with distributed trust assumptions. Nor do they spend three years designing said transparency log. Nor do they care about their USB authenticators being open-source hardware that uses a measured boot KDF instead of the verified boot approach. Nor do they design those devices using open-source tooling (Kicad, Yosys) or spend time and money reversing the NVCM programming and locking feature so they can lock their FPGAs using open-source tooling. But my companies do. We endeavour to advance the state-of-the-art in trustworthy computing, similarly to how my first company (Mullvad VPN) advances the state-of-the-art of what a privacy-focused VPN service should do. :)