Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hardware Attestation as Monopoly Enabler

grapheneos.social

Post reply on HN
Print view View original

261–270 of 799 posts

Re: Hardware Attestation as Monopoly Enabler

#261

Post by AnthonyMouse »

coppsilgold wrote: post #249
AnthonyMouse wrote: post #241

Earlier quoted context omitted.

> But once you get the response you can unblind the signed signature and obtain the token (which is just the unblinded signature). The premise of this is to keep the person issuing the tokens and the person accepting them from correlating you. The issue is when you have more than one service accepting them. You go to use Facebook and WhatsApp but they're both Meta so you present the same unblinded signature to both s…

> you present the same unblinded signature to both services You would never do this as it defeats the entire purpose of using blind signatures to begin with.

That's the point. You go to example.com and get the "sign in with Google" box as the only login option, but now you can't have separate uncorrelated Google accounts. Or if browsers do it automatically then every site does a background load or redirect through adtracker.nsa so you're presenting the same token on every service.

It's not the user who wants any of this to begin with. "You would never do that" except that it's now the only way to be let into the service.

Re: Hardware Attestation as Monopoly Enabler

#262

Post by AnthonyMouse »

nullc wrote: post #253
AnthonyMouse wrote: post #178

Earlier quoted context omitted.

> The other is that because it's not possible to link an attestation to a particular device the only mitigation to abuse that is feasible is rate limiting I still don't see how you can keep something anonymous and still rate limit it. If a service can tell that two requests came from the same party in order to count them then two services can tell that two requests came from the same party (by both pretending to be t…

Just to give an example to prime your intuition: define your "usage token" as H(private_key|service_domain_name|date|4-bit_counter). Make your scheme provably reveal the usage token when you authenticate. Now you can use the service 16 times a day on a particular domain and no more simply by blocking token reuse. And yet the service has no ability to link different tokens to each other or to a specific person because…

> define your "usage token" as H(private_key|service_domain_name|date|4-bit_counter)

But how are you preventing multiple services from using the same value for service_domain_name because they're cooperating to correlate your use?

Re: Hardware Attestation as Monopoly Enabler

#263

Post by nullc »

surajrmal wrote: post #143
zb3 wrote: post #24

Earlier quoted context omitted.

It's a different thing if banking/government apps require a device certified for security, and a different thing if this certification certifies that the user's device has Google spyware preinstalled with elevated privileges.. Google doesn't certify devices basing on security, so that kind of attestation should have no place in banking/government apps, otherwise it just enforces the duopoly

It's hard to listen to arguments when everything is so hyperbolic. The stated rationale for attestation for captcha is to ensure there is a human on the other end and not a bot. This requires a system which is not capable of automated input. The other use case is for ensuring that an application is running on a system which protects the app from being tampered with (by the user, malware, or otherwise). While that see…

> it is a legitimate desire from an application developer

I want a pony! A legitimate desire. So it's okay if I rifle through your underwear drawer in case there are any ponies I could take?

Requiring there be a physical phone is a speedbump at best ( https://i.dailymail.co.uk/i/pix/2017/05/12/13/403C0D44000005... ) and so de-anonymizing every person using the internet by attaching them to a device and allowing google to track them is not sufficient, nor is the privacy loss necessary for the kind of improvement they could realistically hope to achieve.

But most over even if the panopticon were highly effective and even if were the only option to achieve that end we should still reject it because it's wrong.

Re: Hardware Attestation as Monopoly Enabler

#264

Post by nullc »

ls612 wrote: post #3

Asymmetric cryptography and its consequences have been a disaster for the human race. I’m not even joking all of the centralization of power and the rise of totalitarianism tech is driving is downstream from asymmetric cryptography.

you don't need asymmetric crypto to make remote attest like this.

Google can put a hmac key in each device which it knows and keeps secret. Device can author authenticated messages using it. Of course, only google can verify them-- but it appears that the workflow in this depends on google in any case and if anything that limitation would be more a feature to them than a bug.

Re: Hardware Attestation as Monopoly Enabler

#265

Post by nullc »

ls612 wrote: post #38
amarant wrote: post #25

Earlier quoted context omitted.

FFS, cryptography is not the problem. How many times will we have to shut down that particular stupidity? Asymmetric cryptography is a corner stone of basically all online secure communications, and has been since before Google and apple were even founded as companies! (First invented in 1970) When did Https ever hurt you? That's built on asymmetric cryptography. Wherever you see the word "secure" it's basically shor…

Easy there I don’t want to take away your encrypted messaging. I’m just pointing out that the technology that enables it also enables the techno-totalitarianism we have been seeing rise since the mid 2010s

You're just not going far enough-- the dual use technology suppressing human liberty in this case isn't asymetric crypto, it's _computing_.

Re: Hardware Attestation as Monopoly Enabler

#266

Post by izacus »

dathinab wrote: post #218
retired wrote: post #66

Earlier quoted context omitted.

So with a single flip of the switch, the president of the USA can shut down our EU Digital Identity Wallet. Why was this decision ever made?

> Why was this decision ever made? because it wasn't made the decision which was made was having a digital ID wallet, that this needs hardware attestation (or something comparable) is somewhat of a direct consequence of existing laws/regulations regarding making IDs forgery safe it also is a phone only application the huge huge majority of phones runs Googled Android/iOS, so you support them if there where a relevant…

Can you show an example of defeating hardware attestation? It would be useful for many 3rd party ROM users.

Re: Hardware Attestation as Monopoly Enabler

#267

Post by nullc »

AnthonyMouse wrote: post #262
nullc wrote: post #253

Earlier quoted context omitted.

Just to give an example to prime your intuition: define your "usage token" as H(private_key|service_domain_name|date|4-bit_counter). Make your scheme provably reveal the usage token when you authenticate. Now you can use the service 16 times a day on a particular domain and no more simply by blocking token reuse. And yet the service has no ability to link different tokens to each other or to a specific person because…

> define your "usage token" as H(private_key|service_domain_name|date|4-bit_counter) But how are you preventing multiple services from using the same value for service_domain_name because they're cooperating to correlate your use?

Because-- in this hypothetical-- your user agent restricts the usage to the name displayed on the screen and also because your agent won't send the same value twice either (it'll increment the counter or tell you that its run out of tokens).

Re: Hardware Attestation as Monopoly Enabler

#268

Post by izacus »

EmbarrassedHelp wrote: post #208
miohtama wrote: post #149

Earlier quoted context omitted.

The Commission got it through on the last round, though, so eventually it passed.

Chat Control hasn't passed yet. But the Chat Control lobbyists are still lobbying for it behind the scenes, and are currently pushing for all phone calls in the EU to be covered. Source: https://www.patrick-breyer.de/wp-content/uploads/2026/05/861... https://digitalcourage.social/@echo_pbreyer

So what should be done about it? EU Commission issue a decree that it should never be spoken or debated again in public? Never proposed? Any other tyrannical idea?

Do you have a list of other things that shouldn't be brought in front of the elected parliament?

Re: Hardware Attestation as Monopoly Enabler

#269

Post by AnthonyMouse »

danielmarkbruce wrote: post #250
AnthonyMouse wrote: post #163

Earlier quoted context omitted.

Not only that, "corruption" is pretty squishy. Let's apply Hanlon's Razor for once. Google et al go to the government and say they've got this attestation thing that can something something security. No one is taking a bribe but also no one they're hearing from is telling them that doing this is going to cement the incumbents. "Security" is good, right? So it makes it into the law. That doesn't meet most formal defin…

Anything involving trust cements the incumbents or at least creates a force to an outcome of few players. It is what it is. It's not a given that it's incompetence.

> Anything involving trust cements the incumbents or at least creates a force to an outcome of few players.

I don't think that's even true, unless you're using "trust" as a synonym for centralization.

Suppose you had actual competing app stores. Google doesn't control which ones you use; you can use Google Play or F-Droid or Amazon or all three at once and anyone can make a new one. You could get Android apps through Apple's store and vice versa. And then you choose who you trust; maybe you only trust F-Droid and Apple and you think Google and Amazon stink. Maybe you install 90% of your apps through F-Droid but are willing to install your bank app on GrapheneOS from Google Play because you trust your bank and you also trust Google enough to at least verify that the bank app is actually from your bank.

This is the thing that doesn't help the incumbents, right? The bank and the customer both trust Google to distribute the bank app but Google isn't allowed to prevent the user from trusting F-Droid for other apps as a condition for getting the bank app from Google Play. You can have trust without centralization.

Re: Hardware Attestation as Monopoly Enabler

#270

Post by nine_k »

izacus wrote: post #266
dathinab wrote: post #218

Earlier quoted context omitted.

> Why was this decision ever made? because it wasn't made the decision which was made was having a digital ID wallet, that this needs hardware attestation (or something comparable) is somewhat of a direct consequence of existing laws/regulations regarding making IDs forgery safe it also is a phone only application the huge huge majority of phones runs Googled Android/iOS, so you support them if there where a relevant…

Can you show an example of defeating hardware attestation? It would be useful for many 3rd party ROM users.

Gaming consoles typically have hardware attestation (as in verified software on verified hardware, sealed), and it has been broken many times in the past.
Post reply on HN