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

Remote Attestation

liamcvw.com

Post reply on HN
Print view View original

31–40 of 113 posts

Re: Remote Attestation

#31

Post by solenoid0937 »

davidfiala wrote: post #28

Attestation of any type: A double edged sword, where you are guaranteed to lose freedom. Attestation entrenches, empowers, and enriches other entities that aren't you. Ironic how this post got upvoted in parallel to polar opposite in the #1 slot: "John Deere owners will get the right to repair equipment under FTC settlement" https://news.ycombinator.com/item?id=48838876 Engineers may debate about what-about-isms of v…

You don't understand the use case or audience of this article:

> If your infra consistently enforces mTLS

This is for mutual authentication in corporate infrastructure. Attestation is a critical security property for these environments.

Re: Remote Attestation

#32

Post by AnthonyMouse »

stingraycharles wrote: post #27
userbinator wrote: post #25

This is the dream of corporate authoritarians everywhere. The dystopian nightmare we all warned about because we saw it coming. "Security" is the "think of the children" fearmongering of the current environment. As one of our Founding Fathers put it: "Those who give up freedom for security deserve neither." Remote Attestation: Just Say No.

Could you elaborate on why this is so evil? Ensuring our remote employees’ machines are secure is a serious problem for us, and it’s absolutely impossible to require employees to be diligent. We require attestation upon connection to our corporate VPN that checks for basic things such as latest security patches, certain tools installed, etc.

When you access a service with your own device, you control what your device does with what they send. You can block ads or malware, inspect code they send you or network traffic you send them to see if it's exfiltrating your private data, extract the data to analyze or keep as evidence when the service is violating a law or contract, write or use third party code to process the data when the service is trying to force a dark pattern interface on you, etc.

If your device will attest that it's running their code then they refuse access to the service under any other conditions, and then you can't do any of those things because their code won't allow it.

It's also a huge antitrust problem because it precludes new independent platforms from being used, since it cements the chicken and egg problem that people won't use a device that can't access existing services and the services won't support a system nobody uses. In other words, WINE is banned and Firefox is banned and everyone is stuck with IE/Edge on Windows forever.

Re: Remote Attestation

#33

Post by solenoid0937 »

zb3 wrote: post #2

It would be a nice addition if big tech didn't abuse this to shove user-hostile software into devices which the user has paid for (like smartphones).. thanks to this attitude, whenever I see "remote attestation" I associate this with "hostile".. > Using a TPM, we can remotely, cryptographically prove a couple of things: Unless there are exploits..

> whenever I see "remote attestation" I associate this with "hostile"

HN is bizarre. This is just standard infrastructure security practice at any tech company of meaningful size. You are misunderstanding the target use case and audience of this article.

Re: Remote Attestation

#34

Post by solenoid0937 »

userbinator wrote: post #25

This is the dream of corporate authoritarians everywhere. The dystopian nightmare we all warned about because we saw it coming. "Security" is the "think of the children" fearmongering of the current environment. As one of our Founding Fathers put it: "Those who give up freedom for security deserve neither." Remote Attestation: Just Say No.

Please stop bashing on things you don't understand. This is standard practice for workload authentication in corporate fleets. The article makes the target audience clear:

> If your infra consistently enforces mTLS

Re: Remote Attestation

#35

Post by what »

zb3 wrote: post #12
lcvw wrote: post #7

Earlier quoted context omitted.

I think consumer devices should have opt-outs for sure. But personally I am much more comfortable with myself and my family having fully locked down apple phones then anything else on the market right now, precisely because of how difficult it is to get persistent malware into that ecosystem.

Out of curiosity, do you like ads? I assume you don't.. so how would you react if Apple followed Google and prohibited ad blocking apps + removed that capability from web browsers? I'd not be able to put up with that, but more importantly, I'd not want to be in the position where I can't even protest anything because there's no alternative to switch to..

When did google prohibit ad blocking in their browser?

Re: Remote Attestation

#36

Post by sfdlkj3jk342a »

solenoid0937 wrote: post #31
davidfiala wrote: post #28

Attestation of any type: A double edged sword, where you are guaranteed to lose freedom. Attestation entrenches, empowers, and enriches other entities that aren't you. Ironic how this post got upvoted in parallel to polar opposite in the #1 slot: "John Deere owners will get the right to repair equipment under FTC settlement" https://news.ycombinator.com/item?id=48838876 Engineers may debate about what-about-isms of v…

You don't understand the use case or audience of this article: > If your infra consistently enforces mTLS This is for mutual authentication in corporate infrastructure. Attestation is a critical security property for these environments.

> Attestation is a critical security property for these environments.

No it's not. Every corporate network to which I've connected worked just fine without it.

Re: Remote Attestation

#37

Post by solenoid0937 »

sfdlkj3jk342a wrote: post #36
solenoid0937 wrote: post #31

Earlier quoted context omitted.

You don't understand the use case or audience of this article: > If your infra consistently enforces mTLS This is for mutual authentication in corporate infrastructure. Attestation is a critical security property for these environments.

> Attestation is a critical security property for these environments. No it's not. Every corporate network to which I've connected worked just fine without it.

[flagged]

Re: Remote Attestation

#38

Post by AnthonyMouse »

Gigachad wrote: post #20
Uptrenda wrote: post #16

It's a nice idea, but I wouldn't design any system on the assumption that a TPM needs to stay secure for the system to be safe. There's been so many exploits. We can consider the iphone as an R & D platform for doing blackbox computations. In that nothing is allowed to run that Apple doesn't want. Protecting that is apples bread and butter and they care about it enough to value critical exploits in the millions. Yet…

The iPhone is actually working really well. There has never been a widespread malware attack on the iphone. Only highly targeted attacks on individuals. And Apple even has an answer for this as well with Lockdown mode which renders all of those previous exploits impossible. There's also Memory Integrity Enforcement on the iPhone 17 chips which makes all memory exploits detectable by the OS so it can trigger a reboot…

Now explain how any of that requires remote attestation.

Re: Remote Attestation

#39

Post by [deleted] »

davidfiala wrote: post #28

Attestation of any type: A double edged sword, where you are guaranteed to lose freedom. Attestation entrenches, empowers, and enriches other entities that aren't you. Ironic how this post got upvoted in parallel to polar opposite in the #1 slot: "John Deere owners will get the right to repair equipment under FTC settlement" https://news.ycombinator.com/item?id=48838876 Engineers may debate about what-about-isms of v…

[deleted]

Re: Remote Attestation

#40

Post by greyface- »

gucci-on-fleek wrote: post #22
greyface- wrote: post #13

Earlier quoted context omitted.

> running the expected payload SGX does not cryptographically guarantee this. It cryptographically guarantees that the processor contains a legitimate provisioning key signed by Intel. Intel pinky promises that its processor will then only use this provisioning key in certain ways. This promise is essentially unauditable, and previous SGX bugs have shown that Intel isn't really in a position to make it anyway.

You are 100% correct, but this is still mostly fine: without SGX, you need to completely trust Signal, since it could trivially modify the server-side code. But with SGX, you only need to trust that Signal and Intel won't both collude. The most likely attacks on Signal involve trusted insiders or configuration errors, and SGX mostly prevents these, since to exploit it, you'd need to bribe insiders in both Signal and…

The path to compromise that you describe exists, of course. But it's not the only way. For example, a zero-day in SGX combined with privileged access to AWS infrastructure could compromise Signal's SGX setup without any knowledge or collusion by Signal or Intel. As you note, it is not unreasonable for a project of Signal's stature to expect to face adversaries with such capabilities.
Post reply on HN