Hacker News Reader

Comment by kfreds | Hacker News Reader

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.

View on HN

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?

Reply on news.ycombinator.com