6 ms·

System Transparency: a security architecture for bare-metal servers

100 points by harporoeder 3y ago

withinboredom 3y ago
Hmm. Isn’t this what secure boot is for? What is the difference and why isn’t it on the front page?
- arianvanp 3y ago
  No. SecureBoot does non of that. SecureBoot is only a signature on the first binary that runs on the system. "Does Microsoft or the alternative CA I added allow this binary to run". That's it. It doesn't say anything about system state; or about the binaries that run after. Measured boot gives you a holistic view of system state that can be verified by a third party. "What binaries are currently running; which ones ran; did a user unlock the disk with the right password; was the firmware modified; did the latest system update run; are the right users on the system". It's extremely powerful. Combined with TPM policies you can do things like "The secret to my service can only be decrypted after the service has securely authenticated with my mesh network and proven its identity to an attestation server and only after 3rd of february 2024". If TPM measured boot is implemented correctly; secureboot is actually redundant. SecureBoot is basically just an allow-list of which bootloaders can run and nothing more. To summarise: * SecureBoot only works at time T0 with Binary b0. But say you install a compromised apt package after booting secureboot is not gonna help you with that * Measured boot is supposed to protect against (or make it cryptographically obvious that it happened) compromise for the entire lifetime of the machine. (Which is what you need if you want to attest that your bare metal servers were not tampered with by law enforcement agencies)
  - 9dev 3y ago
    It sure sounds useful. It also sounds like it could be used to constrain user freedom once and for all.
    - megous 3y ago
      It also sounds like non-sense. "Measured" boot's core tech is "updating some write only registers in TPM". So as long as you use OS that does not check these registers, you're fine. (Other than the whole "Secure" (should have been called Restricted Boot, but whatever) boot thing, but that's nothing new and still can be disabled on most systems.)
  - Bognar 3y ago
    Secure Boot also validates UEFI Option ROMs, not just bootloaders.
- Bognar 3y ago
  How do you validate that you're on a machine running secure boot? How about when you connect remotely?
  - withinboredom 3y ago
    > How do you validate that you're on a machine running secure boot? That sounds suspiciously like a human problem and not a technical one. In other words, humans configured the server, not a machine. But, humans forget sometimes... and for that `mokutil --sb-state` will save the day.
    - withinboredom 3y ago
      I don’t know why I am getting downvoted. We are talking about physical machines that someone had to physically connect hardware to and not a vm that can simply be provisioned via cloud init. Maybe it was pxe booted, but you’d have to really try to get homogeneous hardware.
m0no 3y ago
Too bad you used Go instead of Rust.
- nablahero 3y ago
  What's the point here of using Rust instead of Go? Go was used because stboot is based on LinuxBoot with u-root (u-root.org) as initramfs builder. What would be the big advantage of using Rust here?
- Always_Anon 3y ago
  Should have used crablang.
goodpoint 3y ago
Interesting but the description is really vague.
- kfreds 3y ago
  Thank you, and I'm sorry about that. I did a talk recently at OSFC which is less vague, but still all over the place. Here's a link to the slides and video. https://www.osfc.io/2023/talks/towards-authentication-of-transparent-systems/ https://www.osfc.io/2023/talks/towards-authentication-of-tra...
- Proven 3y ago
  [dead]
rollcat 3y ago
I'm having a hard time swallowing remote attestation as a concept. You can prove your system *thinks* it runs the same firmware/config/OS as intended by the operator, but you're still vulnerable to a broad range of hardware/OS bugs. If e.g. your NIC firmware gets hit with an APT and quietly starts doing DMA to exfiltrate data, does the system still show green on boot? How do you even verify blobs, yes you can decompile but what good does it do if you don't have the chip spec? I think IOMMU brings far more value. And then the scary prospect where the same tech gets shoved into consumer PCs and used against the interests of the machine's owner. It's true this is useful in a corporate setting, but it's walking a thin line, one that e.g. Google would be happy to cross with something like WEI.
- 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
I invented System Transparency. Ask me anything. :) In short, System Transparency aims to make the reachable state space of a remote system discoverable. If that sounds interesting to you, be sure to check out these two related projects: Sigsum - a transparency log with distributed trust assumptions. Tillitis TKey - an open-source hardware FPGA-based USB authenticator with a measured boot KDF. The Sigsum project is the most mature of the three, having reached v1 just a week ago after three years of design and development. TKey is available for purchase since May, through Tillitis AB. All three projects were initially research projects, led by me, internally at Mullvad VPN. Out of the three System Transparency is by far the most complex and ambitious. The website is quite outdated but we're working on that.
- arianvanp 3y ago
  I love the idea behind TKey. It would be great if there was a kernel device driver for TKey-like devices (Based on a latching KDF) as an alternative for TPMs as it sounds way simpler and easier to secure
  - kfreds 3y ago
    Thank you! We actually started prototyping an open-source hardware TPM but put that project on the shelf to focus on what became the TKey. As you may know, in order to use the TKey as a TPM we'd have to design hardware that can connect to the LPC bus. One of the essential features of a TCG TPM is that is it connected to the reset line of the x86 SoC. Which reminds me, Tillitis is soliciting requests for what our next hardware product should be. :)
    - traceroute66 3y ago
      > Which reminds me, Tillitis is soliciting requests for what our next hardware product should be. :) An HSM. Please please let it be an HSM ! :) There is the YubiHSM, which granted is cheaper than traditional HSMs, but still wildly over-priced at almost 1000EUR each. The world really needs an HSM at a truly competitive price point.

100 points by harporoeder 3y ago

withinboredom 3y ago

Hmm. Isn’t this what secure boot is for? What is the difference and why isn’t it on the front page?

arianvanp 3y ago
No. SecureBoot does non of that. SecureBoot is only a signature on the first binary that runs on the system. "Does Microsoft or the alternative CA I added allow this binary to run". That's it. It doesn't say anything about system state; or about the binaries that run after. Measured boot gives you a holistic view of system state that can be verified by a third party. "What binaries are currently running; which ones ran; did a user unlock the disk with the right password; was the firmware modified; did the latest system update run; are the right users on the system". It's extremely powerful. Combined with TPM policies you can do things like "The secret to my service can only be decrypted after the service has securely authenticated with my mesh network and proven its identity to an attestation server and only after 3rd of february 2024". If TPM measured boot is implemented correctly; secureboot is actually redundant. SecureBoot is basically just an allow-list of which bootloaders can run and nothing more. To summarise: * SecureBoot only works at time T0 with Binary b0. But say you install a compromised apt package after booting secureboot is not gonna help you with that * Measured boot is supposed to protect against (or make it cryptographically obvious that it happened) compromise for the entire lifetime of the machine. (Which is what you need if you want to attest that your bare metal servers were not tampered with by law enforcement agencies)
- 9dev 3y ago
  It sure sounds useful. It also sounds like it could be used to constrain user freedom once and for all.
  - megous 3y ago
    It also sounds like non-sense. "Measured" boot's core tech is "updating some write only registers in TPM". So as long as you use OS that does not check these registers, you're fine. (Other than the whole "Secure" (should have been called Restricted Boot, but whatever) boot thing, but that's nothing new and still can be disabled on most systems.)
- Bognar 3y ago
  Secure Boot also validates UEFI Option ROMs, not just bootloaders.
Bognar 3y ago
How do you validate that you're on a machine running secure boot? How about when you connect remotely?
- withinboredom 3y ago
  > How do you validate that you're on a machine running secure boot? That sounds suspiciously like a human problem and not a technical one. In other words, humans configured the server, not a machine. But, humans forget sometimes... and for that `mokutil --sb-state` will save the day.
  - withinboredom 3y ago
    I don’t know why I am getting downvoted. We are talking about physical machines that someone had to physically connect hardware to and not a vm that can simply be provisioned via cloud init. Maybe it was pxe booted, but you’d have to really try to get homogeneous hardware.

m0no 3y ago

Too bad you used Go instead of Rust.

nablahero 3y ago
What's the point here of using Rust instead of Go? Go was used because stboot is based on LinuxBoot with u-root (u-root.org) as initramfs builder. What would be the big advantage of using Rust here?
Always_Anon 3y ago
Should have used crablang.

goodpoint 3y ago

Interesting but the description is really vague.

kfreds 3y ago
Thank you, and I'm sorry about that. I did a talk recently at OSFC which is less vague, but still all over the place. Here's a link to the slides and video. https://www.osfc.io/2023/talks/towards-authentication-of-transparent-systems/ https://www.osfc.io/2023/talks/towards-authentication-of-tra...
Proven 3y ago
[dead]

rollcat 3y ago

I'm having a hard time swallowing remote attestation as a concept. You can prove your system *thinks* it runs the same firmware/config/OS as intended by the operator, but you're still vulnerable to a broad range of hardware/OS bugs. If e.g. your NIC firmware gets hit with an APT and quietly starts doing DMA to exfiltrate data, does the system still show green on boot? How do you even verify blobs, yes you can decompile but what good does it do if you don't have the chip spec? I think IOMMU brings far more value. And then the scary prospect where the same tech gets shoved into consumer PCs and used against the interests of the machine's owner. It's true this is useful in a corporate setting, but it's walking a thin line, one that e.g. Google would be happy to cross with something like WEI.

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

I invented System Transparency. Ask me anything. :) In short, System Transparency aims to make the reachable state space of a remote system discoverable. If that sounds interesting to you, be sure to check out these two related projects: Sigsum - a transparency log with distributed trust assumptions. Tillitis TKey - an open-source hardware FPGA-based USB authenticator with a measured boot KDF. The Sigsum project is the most mature of the three, having reached v1 just a week ago after three years of design and development. TKey is available for purchase since May, through Tillitis AB. All three projects were initially research projects, led by me, internally at Mullvad VPN. Out of the three System Transparency is by far the most complex and ambitious. The website is quite outdated but we're working on that.

arianvanp 3y ago
I love the idea behind TKey. It would be great if there was a kernel device driver for TKey-like devices (Based on a latching KDF) as an alternative for TPMs as it sounds way simpler and easier to secure
- kfreds 3y ago
  Thank you! We actually started prototyping an open-source hardware TPM but put that project on the shelf to focus on what became the TKey. As you may know, in order to use the TKey as a TPM we'd have to design hardware that can connect to the LPC bus. One of the essential features of a TCG TPM is that is it connected to the reset line of the x86 SoC. Which reminds me, Tillitis is soliciting requests for what our next hardware product should be. :)
  - traceroute66 3y ago
    > Which reminds me, Tillitis is soliciting requests for what our next hardware product should be. :) An HSM. Please please let it be an HSM ! :) There is the YubiHSM, which granted is cheaper than traditional HSMs, but still wildly over-priced at almost 1000EUR each. The world really needs an HSM at a truly competitive price point.