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?
2,639 karma · joined June 16, 2012
Obsessed with building more trustworthy systems.
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. :)
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?
Which reminds me, Tillitis is soliciting requests for what our next hardware product should be. :)
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.
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.
https://www.osfc.io/2023/talks/towards-authentication-of-tra...
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.
By the way, I was confused by how you equated architecture and RTL. In this context I use "architecture" to mean ISA. I use "microarchitecture" to refer to how e.g. its performance characteristics are realized, like IPC.
You seem to know more than I do and would love you to comment. Thanks!
The people and projects surrounding the OSFC has been working tirelessly for many years on changing things for the better. I can personally attest to the fact that the people involved are incredibly passionate about open source firmware.
Making firmware open source benefits vendors AND users. It serves commercial interests AND software freedom.
The conference's scope is open source firmware in general, as implied by its name.
> I'm gonna assume this is PC firmware based on the list of players, but I haven't been able to find any conclusive information on the website.
The landing page lists ARM as one of the sponsors. The same page also features a list of projects that are represented at the conference. Quotes from their landing pages follow:
- coreboot is ... on modern computers and embedded systems.
- Trusted Firmware provides a reference implementation of secure software for Armv8-A, Armv9-A and Armv8-M.
- The OpenBMC project is a Linux Foundation project whose goal is to produce a customizable, open-source firmware stack for Baseboard Management Controllers (BMCs).
- "oreboot for ARM", "oreboot for RISC-V HiFive Unleashed"
- Welcome to TianoCore, the community supporting an open source implementation of the Unified Extensible Firmware Interface (UEFI).
- u-bmc is a Linux OS dist ... tailor made for baseboard management controllers.
- U-Boot mentions on their landing page too many architectures and vendors to list here, but here's a few: ARC, M68K, MIPS, Xtensa.
I'm beyond impressed with the hard work and passion of its participants. Many of them have worked tirelessly for years on advancing the state of open source firmware in the industry. Some of them have been at it for decades.
Everyone I've spoken with at the event clearly recognize how critical open source firmware is to ensuring platform reliability, resiliency and user control.
> ISPs learned how to be bad from security experts explaining how much mischief a person could get up to and deciding that sounded like a swell idea
Telecommunications companies have played a central role in government surveillance schemes for at least 50 years, well before the advent of WiFi. ECHELON was fairly extensively reported on in the late 90's.
> it might have seemed like you heard about ISPs and hackers around the same time
I connected to the Internet around 1993, but my interest in computer security didn't start until around 1996. I'm not sure if that qualifies.
Here's how I think about customer segments:
* Those interested in online privacy
* Those interested in circumventing censorship
* Those interested in a secure network channel from their machine to "The Internet", by which I mean secure from their local ISP eavesdropping on them.
* Those interested in circumventing geographical restrictions.
Due to the nature of the Internet and how its most important protocol (IP) works, changing your IP address is a necessary, but not necessarily sufficient, step in protecting your privacy online. This fact says something about the long term relevance of VPNs, Tor, and similar technologies.
Source: I'm one of the co-founders of Mullvad VPN.
This is an excellent heuristic. Personally I like to evaluate trustworthiness in terms of integrity and competence - can I trust their values and can I trust that they know what they are doing? Words are cheap of course. Consistent action across several years is much harder to fake. It also overlaps with another heuristic I use to model and predict the behaviour of a company; a company's behaviour will converge on the shareholders' goals over time.
> This "our servers have no disks" thing is kind of thing is marketing.
You are correct that we considered that aspect while writing the blog post, but please read the content before passing judgement. See the section titled "To recap about “no disks in use”" in particular.
On the topic of "air of legitimacy" I'll just leave these here:
* Our apps have been open-source since we launched in 2009
* Our response to Shellshock: https://news.ycombinator.com/item?id=8385332
* Our thoughts on WireGuard in 2017: https://mullvad.net/en/blog/2017/9/27/wireguard-future/
* Experimental post-quantum KEM support in 2017: https://mullvad.net/en/blog/2017/12/8/introducing-post-quant...
The blog post you commented on also talks extensively about how it was one of our first steps in making our infrastructure transparent. Here are just two things we've done as part of that project:
* "This is the first time a modern off-the-shelf server platform gains coreboot support, and it is an integral part of realizing our vision of transparent and independently auditable VPN servers." - https://mullvad.net/en/blog/2019/8/7/open-source-firmware-fu...
And finally, we've spent 2-3 years designing a transparency log with distributed trust assumptions. One of many critical parts necessary to achieve our vision of transparent server infrastructure. I'll wager that there's no transparency log with a stronger threat model than ours. https://www.sigsum.org
We're certainly not without fault, but hopefully this helps inform your opinion of Mullvad.
Best regards, Fredrik Stromberg (co-founder of Mullvad VPN, Tillitis, Glasklar Teknik)
Here's a complete list of settings and modifications:
Our decision to remove port forwarding was not a question of margins - it was a moral and practical decision.
Port forwarding is a feature with many legitimate use cases. This year it became clear that we had become popular for use cases we didn't want to support. Undesirable content and malicious services is a good summary. I'm not privy to more details than that as my main focus is research.
Technology is often a double-edged sword, but thankfully it is often also a net benefit to its users and society in general. Privacy online is exactly that kind of technology. Enabling anyone to host any service anonymously on the open Internet is another matter.
I hope AirVPN and AzireVPN somehow succeed with providing that feature while steering clear of its downsides. That would be awesome.
Nitpick: Mullvad is older than both Air and Azire. :)
Announcing the removal of a feature such as this a mere 30 days ahead is not how we like to conduct our business in the general case. I expect those of our customers who relied on this feature to be disappointed by its removal as well as the manner in which it was done.
Nevertheless it was the right thing to do. The manner and extent in which it came to be abused in recent months made it unacceptable for us to continue providing it. This feature should have been removed a long time ago, with a longer grace period. It wasn't - a mistake on our part - and some of our users suffered for it, including you. For this I am sorry.
Affected customers can get their money back for any prepaid service they can not use, of course.
If you used port forwarding to (I) make a service reachable (II) from the open Internet there are plenty of good hosting providers which will happily take your business.
If you used port forwarding to (III) stay anonymous while (I) making a service reachable we can highly recommend Tor's "onion service" feature. It was built with that use case in mind.
If you used port forwarding to (III) stay anonymous while (I) making a service reachable (II) from the open Internet, there are no good options that we can recommend.
Port forwarding needed to be removed on moral grounds. It needed to be removed because it was causing too much of a disturbance to our core mission of making mass surveillance and censorship ineffective.
I hope my explanation has - if not allayed your disappointment - at least provided some clarity.
Best regards, Fredrik Stromberg (cofounder of Mullvad VPN)
Our first product is the TKey - a new kind of USB security key - which we have been selling since May. TKey is very likely the most open source USB security key in the world, as well as the first one to feature unconditional measured boot, which we use as a method for key derivation.
Tillitis AB is a sister company of Mullvad VPN AB and Glasklar Teknik AB.
TKey is based on ideas like TPM and DICE. Think of TKey as a TPM-in-time, and a discrete TPM on an x86 mainboard as a TPM-in-space. Both go through the load-hash-measure-trust/execute steps, but TKey only needs one hardware domain to accomplish this whereas a discrete TPM needs two.
Measurements and their results need to be computed in a context that can't be subverted by the object that is being measured. In the discrete-TPM case the host loads and hashes the object and then sends it to the TPM before letting the object influence the host's control flow.
The only difference in the TKey case is that instead of sending the hash to a TPM the TKey derives key material based on Hash(sk, Hash(object)) and then removes sk from RAM. This is roughly equivalent to TPM sealing.
The TKey equivalent of TPM quoting/attestation would involve a signing step using sk, and leaving the resulting certificate in RAM before letting the object influence control flow. A downside to this approach is that each measurement creates another level in a PKI-like structure. If you do the same thing with a discrete TPM you can do multiple measurements and still only have one signature attesting all of them.
That's the gist of it.
If you think this is interesting I can highly recommend you check out Sigsum - our transparency log design for signed checksums. We've been developing it for a few years and will most likely toggle it version 1 this spring. Here's its threat model:
Sigsum is designed to be secure against a powerful attacker that controls:
- The signer’s secret key and infrastructure - The log’s secret key and infrastructure - A threshold of so-called witnesses that cosign the log
Another project that started at Mullvad VPN and is now its own company is Tillitis. Its first product is an open source hardware USB device with unconditional measured boot and key derivation inspired by DICE. Everything from source code to Verilog and KiCad files are on GitHub. Enjoy!
Cheers, Fredrik Stromberg
(Disclosure: I cofounded Mullvad VPN, invented System Transparency, co-designed Sigsum, co-designed TKey, and cofounded Tillitis)
- It is supported by an open-source FPGA toolchain
- Has an in-package non-volatile configuration memory (NVCM) that is lockable. This is where we'll eventually keep the FPGA configuration bitstream, including the unique per device secret.
After some reverse-engineering work we're also able to program and lock NVCM with open tooling, as opposed to having to use Lattice's proprietary one.
Yes, that'd be possible. I don't know how webauthn works, but if it relies on ECC you could probably do ECDH between all security keys you wanted to carry your master key, and then use the combined ECDH values as the master key.