Zero-Knowledge Proofs for Private Web Attestation with Multi-Vendor Hardware | Hacker News Reader

Zero-Knowledge Proofs for Private Web Attestation with Multi-Vendor Hardware

blog.cloudflare.com

50 pointsdane-pgp6 comments

> We also need a safe way for users of devices not on our list to send their key to us and demonstrate that it should be trusted

This point is sort of hidden away at the bottom of the article, although nearer the top they do boldly assert:

> Trustworthiness is determined by the FIDO MetaData Service.

It might seem like the proposed scheme is no different from the standard Web PKI system of certificates and certificate authorities (with FIDO taking the place of the CA/Browser Forum), but there's a fundamental difference:

The browser, as a user agent, can be configured to trust a self-generated CA cert so you can access any site you want, but we are moving to a world where big companies get to place requirements on the sorts of devices you own - devices which by their nature have to keep secrets from you.

This brave new world may prove to be genuinely better for security and even privacy, but I still think there are important unanswered questions, and not just the ones that the article glosses over with a "we also need". For example, is FIDO really going to brick 100,000 devices because someone managed to extract a key from one of them with an electron microscope? If each device costs $10, then that's $1,000,000 of damage, which is a tempting target to nation states or just bored college students.

It's not really bricking as the devices still work and remain as secure as they were before for the user specific keys, they simply fail attestation for cases where someone cares if the user is using a real and secure device. I.e. Banks/wallet services and cloudflare given their fear of Sybil attacks.

Personally, I would rather my banks accept Fido keys and tell me when I might need to replace one. Since the user keys are still fine, they technically only need to prevent the sign up of new keys if they trust information on when a device was compromised.

People compromising them for fun and publishing their success is much better than no one being interested in their security and no one knowing whether it is hard or easy to be a secret builder of malicious clone tokens.

> We take privacy seriously at Cloudflare, and want to avoid learning any information that could identify you.

While there are a lot of technical details I could go into about designing security protocols like this, and many security protocols I have evaluated really just reduced to a core proof wrapped in a bunch of adjacent shell game obfuscations, the only thing worth trusting is the incentives.

Why does Cloudflare want to avoid identifying you?

While it's very cool that Cloudflare is so enthusiastic about new protocols and sharing the details, the technical description in the article describes everything except a protocol that someone with domain competence could reason about directly, while providing exposition on things like curves, external standards, and the ZK protocol it hinges on is buried.

Is there a version of this article with a sequence diagram of the protocol, or a BAN logic spec? Having read the article, I am finding it difficult to ascertain what I should find trustworthy, new, or different about the proposal.

I tell developers and architects all the time, if they can't express their security protocol in terms and syntax of a protocol like these, I'm going to assert they are full of it: http://www.lsv.fr/Software/spore/table.html I am pretty sure cloudflare and the author are not full of it, but some effort to give a nod to convention and demonstrate it would go a long way. Admittedly I'm talking my book here because writing stuff like this has been a big part of my consulting work over the years, but the better developers and even non-experts can reason about proofs and security protocols, the better and more successful they're going to be.

Hi, the author of the blog here. The protocol is published as part of the Selected Areas in Cryptography conference and is also on eprint (https://eprint.iacr.org/2021/1183).

Awesome, thank you, I will watch for it! The source of the comment was that architects making decisions need to be able to reason about it. The virtuosity in the article is apparent, where my practitioners view at perhaps a higher layer of abstraction is mainly a question of where the risk goes, who holds it, and how the protocol distributes it.

It looks like a great solution to attest I have a FIDO key without exposing who I am. But how do they know I'm a human? Because I have a FIDO key? Seems like one human can buy many keys.

Reply on news.ycombinator.com