System Transparency: a security architecture for bare-metal servers | Hacker News Reader

System Transparency: a security architecture for bare-metal servers

system-transparency.org

100 pointsharporoeder27 comments

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.

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

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. :)

> 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.

> An HSM. Please please let it be an HSM ! :)

That is one of the options we're considering, but please tell me more. :)

What companies, communities or individuals are missing what features at what price point?

The devil's advocate would argue that it can't be that important if the customer isn't willing to pay 1,000 EUR per HSM. Do you care about certifications such as FIPS or CC? If so, is this simply a matter of achieving compliance at the lowest cost rather than security?

In terms of YubiHSM, they make two versions, the non-FIPS and the FIPS.

My original post was made with the non-FIPS version in mind, which is effectively a non-certified glorified Yubikey that just has different firmware that allows HSM-esque functionality such as key-wrap, and a more API-friendly interface even if the documentation is terrible. :)

I agree that for FIPS/CC, by all means charge what you like for the certification badge, since any company that needs the compliance tick-box will pay whatever price is asked. My beef is more with the non-certified pricing.

Ultimatley the problem is when you clearly need more than one, and ideally minimum of three or five units in order to achieve suitable hardware redundancy. The sort of people I have in mind would be private individuals (e.g. freelance developer, OSS-project maintainer etc.) and SME-sized companies and non-profit organisations for whom 3x650 or 5x650 could be financially unattractive or even plain financially impossible.

Perhaps we could meet half-way and you could have basic functionality and then more advanced functionality and/or increased storage capacity unlockable through software licensing on a pay-as-you-go model ? As long as the fees were one-off and not yet-another-company-selling-a-subscription-pricing-model.

How far up the stack does the verification go? Most secure boot stacks give up after the initramfs because disk images are usually mutable. Do you make any attempts to go further?

> Do you make any attempts to go further?

Yes.

At the moment we're targeting x86-64 servers with UEFI. On such platforms we aim to do the following:

1. UEFI does measurement and verification of stboot using UEFI Secure Boot

2. stboot does measurement and verification of stvmm

3. stvmm does measurement and verification of Guest VMs

4. Clients use STAM to verify Guest VMs when establishing a secure connection

* UEFI Secure Boot is 2048-bit RSA.

* Measurements are done assuming the platform has a TPM.

* stboot will do m/n signature verification for source release, reproducibility and build release, as well as verify Sigsum log inclusion. (Ed25519)

* Sigsum log inclusion is just another detached signature blob, containing an inclusion proof, and signatures on that proof from the log operator and m/n cosigning witnesses.

* stvmm will be Linux KVM + Firecracker, and an authenticated API for listing, starting and stopping VMs.

* STAM is the System Transparency Authentication Mechanism.

For more details, see my recent talk at OSFC, linked elsewhere in this thread. It's admittedly a bit all over the place.

Have you been following the emerging RATS and SCITT specifications in IETF? Someone with your work and knowledge could be a great contributor.

Not very closely, although I am aware of them. Are you involved? How would you relate RATS and SCITT to System Transparency, Sigsum and TKey?

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.

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.

> 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).

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. :)

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

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)

It sure sounds useful. It also sounds like it could be used to constrain user freedom once and for all.

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.)

Secure Boot also validates UEFI Option ROMs, not just bootloaders.

How do you validate that you're on a machine running secure boot? How about when you connect remotely?

> 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.

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.

Interesting but the description is really vague.

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-tra...

Too bad you used Go instead of Rust.

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?

Should have used crablang.

Reply on news.ycombinator.com