←back to thread

596 points pimterry | 2 comments | | HN request time: 0.407s | source
Show context
toyg ◴[] No.36863175[source]
This might be where the internet really gets forked, as it's been predicted over and over since the '90s.

On one side, we'll have a "clean", authority-sanctioned "corpweb", where everyone is ID'ed to the wazoo; on the other, a more casual "greynet" galaxy of porn and decentralized communities will likely emerge, once all tinkerers get pushed out of corpnet. It could be an interesting opportunity to reboot a few long-lost dreams.

replies(16): >>36863389 #>>36863444 #>>36863448 #>>36863559 #>>36863564 #>>36863569 #>>36863656 #>>36863710 #>>36863719 #>>36863948 #>>36864147 #>>36865104 #>>36865427 #>>36865627 #>>36866079 #>>36871323 #
TheNewsIsHere ◴[] No.36863656[source]
The problem I have with this web attestation concept generally is that I really want it _inside_ my shiny SSO-everywhere-Zero-Trust-at-the-edge-mTLS-everywhere business network.

I also kind of want it in the public-cloud-meets-private-use home environment (that is, my Cloudflare Access tunnels and MS365 business tenant I use for private stuff).

I don’t want it to touch my personal browsing experience or in any way involved in my personal-use browser environments.

These are effectively opposed desires at this point, and it’s a cat-out-of-the-bag technology.

replies(3): >>36863783 #>>36865952 #>>36873614 #
mindslight ◴[] No.36865952[source]
These desires are not mutually opposed!

The fundamental problem with current remote attestation schemes is the corporate-owned attestation key baked in at the factory [0]. This allows the manufacturer to create a known class of attestation keys that correspond to their physical devices, which is what prevents a user from just generating mock attestations when needed.

If manufacturers were prohibited from creating these privileged keys [1], then the uniform-corporate-control attestation fears would mostly vanish, while your use cases would remain.

A business looking to secure employee devices could record the attestation key of each laptop in their fleet. Cloud host auditors could do the same thing to all their hardware. Whereas arbitrary banks couldn't demand that your hardware betray what software you're running, since they'd have no way of tying the attestation key to a known instance of hardware.

(The intuition here is similar to secure boot, and what is required for good user-empowering secure boot versus evil corporate-empowering secure boot. Because they're roughly duals.)

[0] actually it's something like a chained corporate signing key that signs any attestation key generated on the hardware, but same effect.

[1] or if the user could import/export any on-chip attestation keys via a suitable maintenance mode. Exporting would need a significant delay of sitting in maintenance mode to protect against evil maid attacks and the like.

replies(1): >>36866870 #
1. TheNewsIsHere ◴[] No.36866870[source]
I agree with you, but I’m not sure making it taboo/criminal/a regulatory violation/prohibited/etc for device manufacturers to embed keys at manufacturing and enabling the resulting attestation capabilities is the right move either.

If I’m Apple, or Google, or Samsung, then I have a genuine interest in device attestation in my own ecosystem for various good reasons. Apple makes extensive use of this capability in servicing, for example. That makes sense to me.

That’s what I mean by a cat-out-of-the-bag technology. Threat actors, counterfeits, and exploits being what they are in this era, it’s almost an inevitability that these capabilities become a sort of generalized device hygiene check. Device manufacturers don’t have to provide these APIs of course, or allow the use of their device attestation mechanisms, but they’d be pressured to by industry anyway. And then we would have something else.

I do like your idea of having the platform bring keys to the table and requiring some kind of admin privileged action to make them useful. But I wonder if we had started that way with web attestation, would it inevitably turn into this anyway?

replies(1): >>36867336 #
2. mindslight ◴[] No.36867336[source]
There are always genuine interests for various good reasons. The problem is that the limitless logic of software creates a power dynamic of all or nothing. Situations are comprised of multiple parties, and one party's "good reasons" ends up creating terrible results for the other parties. For example, Apple's attestation on hardware they produced now becomes a method to deny you the ability to replace part of your phone with an aftermarket part, or to unjustly deny warranty service for an unrelated problem.

So no, I do not buy the argument that we should just let manufacturers implement increasingly invasive privileged backdoors into the hardware they make, as if its inevitable. With the mass production economics of electronics manufacturing, the end result of that road can only be extreme centralization, where a handful of companies outright control effectively all computing devices. If we want to live in a free society, this must not be allowed to happen!

> But I wonder if we had started that way with web attestation, would it inevitably turn into this anyway?

The main threat with web attestation is that a significant number of devices/customers/visitors are presumed to have the capability, so a company can assert that all users must have this capability, forgoing only a small amount of business (similar how they've done with snake oil 2FA and VOIP phone numbers, CAPTCHAs for browsing from less-trackable IPs, etc). So creating some friction such that most devices don't by default come with the capability to betray their users would likely be enough to prevent the dynamic from taking off.

But ultimately, the point of being able to export attestation keys from a device is so that the owner of a device can always choose to forgo hardware attestation and perform mock attestations in their place, regardless of having been coerced into enrolling their device into an attestation scheme.