kfreds

> From the photo, that looks like a stock iCE40 FPGA, which does not support hardware attestation of the loaded bitstream.

Which FPGA models support _attestation_ of the loaded bitstream? Do any?

> How does the user verify that the FPGA loaded the expected bitstream instead of something with a backdoor?

It's a Lattice ice40up5k, which contains a programmable and lockable NVCM memory in-package. The engineering samples we handed out today at OSFC store the FPGA configuration bitstream on a SPI flash memory though.

> A DICE chain that is not rooted in physical, immutable hardware isn't very useful.

When we start selling them we'll likely sell both security keys with pre-provisioned bitstreams in NVCM as well as unprovisioned security keys so you can provision your own.

> One question, with the two-stage approach, isn’t that a security risk? App 1 gets measured and can’t change, but it needs to identify app 2 in a way that still allows it to be updatable, invalidating the whole security chain.

It doesn't invalidate it if it works as the application developer intended. The essential idea is that the first mutable boot stage contains a trust policy which somehow verifies the second stage. Let's say that's a valid signature over the hash value of the second mutable stage. The trusted public key in contained in the first stage.

What we've done there is first used measured boot, and then verified boot.

Measured boot is basically load-hash-measure-execute, where "measure" means "store the hash value of whatever I'm about to execute somewhere safe where the soon executed thing won't be able to undo my storing of its hash".

Verified boot on the other hand is about verifying the next stage and only execute it if it verifies as valid by the trust policy.

> I’m probably not understanding something, so I’d love an explanation (preferably one that non-cryptographers understand)

Honestly I'm beginning to realize it's not all that simple to explain.

Yes, I'm aware of it. I'm not sure if it's small enough for the Tillitis Key to be able to use it.

Good explanation. Thank you.

I'm not sure I understand your question.

If you're asking about applications running on the device (Tillitis Key) the answer is measured boot. You can read more on tillitis.se.

> The things you have listed are indeed very nice, but they are not new kind, as they are available elsewhere.

Really? I wasn't aware that there is another USB security key with measured boot-based key derivation. Please provide a link!

> Can you give a bit more compare and contrast to the original question?

Except for Tillitis Key, all USB security keys I'm aware of either boot any software, or only boot software that has been signed with a key pair. Tillitis Key is different in that it measures the application, and uses that measurement to derive a secret specific to the application as well as the stick it's running on.

Yes, except YubiHSM boots using verified boot. In the case of Tillitis Key each program gets its own secret key, which it can use to e.g. derive a key pair.

> Would the Tillitis Key be able to securely store a private key, then with appropriate authentication from the host, use that key for encryption and decryption?

Yes. I don't think that would be very hard to do.

Thanks! The other news of today is that we've started a second sister company - Glasklar Teknik AB - which will focus on maintenance and development of System Transparency and Sigsum.

System Transparency: Mullvad's security architecture we'll use to eventually make our running VPN systems transparent.

Sigsum: A transparency log design with distributed trust assumptions (witness cosigning).

1. The hardware contains a UDS (unique per device secret) which can only be read once per boot cycle.

2. Firmware in ROM does unconditional measurement of the first mutable boot stage, which is loaded from the host, over USB.

The KDF used for measurement is Blake2s(UDS, Blake2s(application), USS).

Note that when I say hardware I mean FPGA hardware design.

Tillitis Key’s design encourages developers to experiment with new security key applications and models in a way that makes adoption easier and less risky for end-users.

You can read more on tillitis.se or in the comment I made below.

Tillitis Key will allow you to chain-load applications. This means that you could have a thin loader which does code signing verification of the next application stage, and hand off the secret to it. Basically it's a trust policy that defines under what circumstances the next application stage gets the secret.

Another trust policy the loader could have is requiring m-of-n code signatures, or perhaps that as well as transparency log inclusion. Check out sigsum.org.

The Tillitis Key is a new kind of USB security key inspired by measured boot and DICE.

Tillitis Key’s design encourages developers to experiment with new security key applications and models in a way that makes adoption easier and less risky for end-users.

It offers both security and flexibility by being end-user programmable while also preventing applications loaded onto the device from knowing each other’s secrets. During use firmware on Tillitis Key derives a unique key for each application it runs by measuring it before execution. This is done by combining an application’s hash value with a unique per device secret. Applications are loaded onto the device from the host computer during use, and are not stored persistently on the device.

A user- or host-supplied secret can also be mixed into the key derivation function, providing further protection. A sophisticated physical attacker should be assumed to have knowledge of the target application’s hash, and will likely eventually succeed in extracting the UDS from the hardware. By adding a host-supplied secret, knowledge of the application used as well as the security key’s UDS is not sufficient to produce the application secret. This makes the security impact of a lost or stolen Tillitis Key less than for conventional security keys.

Device applications can be chain-loaded where the first application stage hands off its secret to the second stage. This improves user experience as it makes it possible for the application secret (and its public key) to remain the same even if a device application is updated. It also enables developers to define their own software update trust policies. A simple first-stage application might do code signing verification of the second stage, whereas a more advanced one will require m-of-n code signatures, or a Sigsum inclusion proof. Sigsum was designed with embedded use cases in mind.

Tillitis Key is and always will be open source hardware and software. Schematics, PCB design and FPGA design source as well as all software source code can be found on GitHub.

https://www.tillitis.se

https://github.com/tillitis/

(Full disclosure: I'm Fredrik Stromberg, cofounder of Mullvad VPN and co-designer of Tillitis Key)

> IP addresses are only one minor tracking mechanism out of many which defeat obscuring originating IP by means of VPN altogether (canvas fingerprint, cookies, font/screen tracking, etc.)

I agree. This is why I said "useful starting point". A user looking for browsing privacy needs to do more than just use a VPN or Tor. Obscuring your IP address somehow is necessary but not sufficient. This is what I meant.

Category: [Misunderstanding]

> You're trying to say if I use a VPN, I get privacy because websites don't know my IP, but this isn't even remotely accurate.

No, I said it's a "useful starting point". I did not say it's sufficient. I could have been more clear, but I was in a hurry when I wrote it.

Category: [Misunderstanding]

> Do you explain this anywhere in your marketing materials?

We do! On our landing page you are met with this:

"... a ... VPN is a good first step toward reclaiming [your right to privacy]."

Right below is a button ("What is a VPN?"), which leads to a page containing a header ("How a VPN protects your privacy"), which explains further:

"Using a VPN is a great first step toward protecting your privacy, but it's not the ultimate solution (we wish it was!). However, it's easy to improve your privacy ninja skills."

The quote above links to a guide explaining what is necessary to protect your browsing privacy: https://mullvad.net/en/help/first-steps-towards-online-priva...

Category: [Question]

With this reply I believe I have shown you that we (Mullvad) do "reason about this in a transparent and objective way", both on your website, and with people giving us feedback.

As an aside I think IVPN's approach might be more to your liking, but nevertheless none of your stated concerns apply to us. As I've shown above they came down to two misunderstandings and a question.

If you have any other concerns I'd love to hear them. I appreciate your feedback. If we only spoke with people who gave us positive feedback we wouldn't improve as much.

Thank you.

I disagree with your assessment of the use cases for a VPN. Just one example: Your IP address is often a great identifier, making a VPN or Tor a useful starting point for online privacy. This is more or less what we say on our website as well.

Based on your comment however I think you might find the follwing links to IVPN refreshing:

https://www.ivpn.net/blog/why-you-dont-need-a-vpn/

https://www.doineedavpn.com/

https://github.com/ivpn/doineedavpn.com

> Why did it take so long to add monero support? It always seemed weird that you went so far for privacy, but didn't support monero. Was it just on the backlog and took a bit of time to implement?

I don't work with payments and the surrounding systems so I don't know the details of the project itself. As an organization we've certainly been aware of the feature request, but until now we've prioritized other projects.

> EDIT: I've heard a rumor that you've shared a user IP because of a government subpoena (live during a connection, so it wasn't logged). Has this happened?

To my knowledge it has never happened in the history of our service.

> EDIT: One other question - is there plans to add more IPs? Services seem to flag most mullvad IPs but I'm not sure there's much you can do about that.

I'm sure my colleagues in the Operations and Support teams are aware of it. You'll get a better answer from support@mullvad.net.

Thank you.

> Not much more you can do in my opinion. It's definitely good enough for me! Thanks for this great service!

Thank you. I happen to think there's a lot more we can do. Look forward to future blog posts. :)

Thank you for the compliment! We are indeed for real, but I don't expect this comment will convince you. I'd love to know what we could do that would change your mind.

The same goes for anyone else reading this. Are you worried that we are too good to be true? What could we do to become more trustworthy in your eyes?

Cheers, Fredrik Stromberg (cofounder of Mullvad)

> Isn't network monitoring and logging the bigger issue for a VPN service?

Great point. I have a hard time comparing the importance of the integrity of our VPN servers with monitoring and logging of network traffic happening upstream of them without a long discussion of the many nuances. Let’s leave it at; they are both very important issues.

> How can you provide transparency of the network?

That’s very hard. Individual AS’s upstream of the VPN server you’re connected to might change their routing at any moment, and suddenly your traffic makes its way through an unexpected AS or jurisdiction, which may change the monitoring situation completely.

Enabling our users to use multiple hops is one mitigation, another is vetting our data center providers. In collaboration with some of our Internet providers in Europe we have deployed protections on layers below IP. Come to think of it, I don’t think we’ve blogged about that. Thanks!

> Where will you draw the line between public and private – at the moment your consumer-facing app is on github, but less "server side" stuff (in common with many other VPN providers).

All source code for all software on our VPN servers must eventually be public, and all build artifacts must be reproducible by 3rd parties.

> I understand that probably you want to keep the database of "active numbers" private, but if I understand you correctly, you want to move to a model where anyone can download your in-memory image, run it in a VM, and audit it independently.

Exactly, but we will also have to measure each artifact in the boot chain into the platform TPM, and allow anyone to issue a challenge to the TPM to get a signed quote of the boot chain measurements.

> I would welcome this. I'm particularly interested in how you maintain access to your bare-metal machines (e.g. do you have ssh / a serial console enabled)

We’ll have to constrain our own ability to access the VPN servers. We cannot be allowed arbitrary root access as that would make the TPM measurements meaningless from an audit perspective. Well, you’d be able to conclude we have root access, so not totally meaningless.

Thank you!

Thank you for asking.

> Why are the servers located in Sweden,

We have 762 servers spread across 38 countries. Less than 10% of our servers are located in Sweden [0].

> a country that's known for online surveillance

My cofounder and I started Mullvad as a protest against the growing mass surveillance of Sweden as well as other countries. Our intent was direct political action through entrepreneurship. Incorporating the company in Sweden was the obvious choice, since we are both Swedes. We felt that incorporating elsewhere would have been more risky, complicated, and costly.

Mullvad has excellent lawyers who continuously monitor the legal situation in Sweden. Right now there is no Swedish law that can compel Mullvad to start logging [1]. Should the situation change we have contingency plans.

[0]: https://mullvad.net/en/servers/ [1]: https://mullvad.net/en/help/swedish-legislation/

System Transparency reduces your trust assumptions on us. As a VPN provider we are in an immense position of power over you. We aim to reduce your trust assumptions on us to a few things that we would need to explicitly lie about in order to betray you.

As an example, let's say that we offered any of our users to at any time during the year show up at our office and inspect our VPN hardware, without warning us beforehand. In that situation, if we wanted to betray your trust and privacy, we would need to put in a lot more effort than if we said "We have secure servers. Trust us on that. No you can't see them.". Does that make sense?

You are correct that System Transparency is not a universal remedy for all threat models. Indeed the word "secure" is undefined until you have a threat model. Most threat models are implied and undocumented assumptions.

At some stage in an R&D project one should shift from exploration to threat model-driven development. Most people, myself included, tend to focus on technical solutions, and argue back and forth how "oh, but it can be broken using X".

System Transparency aims to provide remote auditability assuming (1) the server hardware specification is correct, (2) a correct cryptographic hash of the contents of the SPI flash containing the platform firmware, and (3) a keypair generated on and only accessible to the platform. This is very simplified of course.

An attacker aiming to tap incoming and outgoing network traffic from our servers, who has physical access to the VPN server's Ethernet port, or an upstream router, isn't in the scope of System Transparency to protect against. We need to use other means for that.

Correct! Thank you for highlighting that.

Here are some additional details for those interested. We intend to make use of TPM for remote attestation of the current boot chain, reproducible builds to provide a strong link from source code to build artifacts, and a transparency log for a historical record of previously used boot chains, artifacts, WireGuard server keys, and related signatures.

As dtx1 mentioned elsewhere in this thread, diskless VPN infrastructure is currently in use by many other VPN providers. That is not a novel feature of course. What is novel is user-auditability of running VPN infrastructure. We were the first VPN provider to state our intention to make our infrastructure user-auditable AND provide a realistic roadmap with the specific technologies needed to do so. See the link above.

I believe the technologies we use in System Transparency will ultimately reshape the VPN provider industry into a highly competitive space focused on maximizing the transparency of VPN infrastructure. Or not, but at least OUR users will be able to audit us. :)

Either way we’re looking forward to the future. The opportunity for improvement is immense.

> Forgive me if I have asked this before. Have you ever considered a Pay as you Go model with minimum top up fees? $50 for 50GB with no expiry you can use it for life?

Yes, but I can't recall the reasons we discarded the idea. Something like this perhaps:

In general I like the idea of VPN as a utility - anonymous internet on tap. Utility-like services in functioning markets compete on price to the benefit of the consumer. On the other hand, things that look like one-dimensional utilities to the consumer isn't always. A service category where there's plenty of innovation potential left shouldn't pretend to be a utility. Especially players who aim to improve state-of-the-art. A pay-as-you-go model encourages consumers to compare quantities of something that is quite disconnected from the quality of what they get.

Paying per month makes more sense to me for another reason as well - It's similar to what we do with our suppliers.

To be fair I think is_true's question is excellent. If anything I should have clarified where I was coming from in my first post. Ultimately I opted for keeping it shorter.

I agree though, it is a real joy to lurk a HN thread on J. Random topic and be treated to high-signal conversations. :)

It does mean something. I can only testify to how they acted in our case of course, but what I can contribute is this:

In a product category which is famous for its high-paying affiliate programs, they chose two players who are smaller and less well-known. Neither of them paid for their reviews. Most of their competitors mentioned in the article do have affiliate programs.

Thank you!

Mullvad: I know it for a fact, because I'm one of the founders.

IVPN: I don't know it, but I've met Nick Pestell (the founder) several times, and he's told me they don't pay for reviews. I trust him.