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

51–60 of 113 posts

Re: Remote Attestation

#51

Post by sfdlkj3jk342a »

solenoid0937 wrote: post #45
sfdlkj3jk342a wrote: post #43

Earlier quoted context omitted.

> Do you debate vaccines with your doctors too? If by "debate", you mean I take their advice into consideration and then make my own decision without blindly trusting them, then yes I do.

I hope you put a lot more research into those debates than you did with this topic! I just don't understand why you'd have this overconfident hot take about a topic you clearly aren't familiar with. Like, try to understand the article subject and audience first?

I didn't claim to be an expert in this particular area of security, but I have enough common sense to know that remote attestation is not "critical" for a corporate network. Perhaps it has valuable use cases for very large companies that want complete control over their employee devices, but your claim is far too broad to hold.

Re: Remote Attestation

#52

Post by fleventynine »

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.

> Every corporate network to which I've connected worked just fine without it.

Just because it appears to be working fine doesn't mean you are in control of it. Without hardware attestation, how do you know the machines are running the software you think they are?

Re: Remote Attestation

#53

Post by bobbiechen »

throwaway7679 wrote: post #11
lcvw wrote: post #9

Earlier quoted context omitted.

I definitely want to do a post on confidential computing as well. Super cool stuff.

Maybe you could do a post on... remote attestation. That is, the thing that people are actually talking about when they use that term: The means for companies and governments to usurp the ownership of consumer devices.

Oh yeah, just like all cryptography is just a way for bad people to hide their criminal activity.

I'd read the confidential computing post! (used to work in this space myself)

Re: Remote Attestation

#54

Post by solenoid0937 »

sfdlkj3jk342a wrote: post #51
solenoid0937 wrote: post #45

Earlier quoted context omitted.

I hope you put a lot more research into those debates than you did with this topic! I just don't understand why you'd have this overconfident hot take about a topic you clearly aren't familiar with. Like, try to understand the article subject and audience first?

I didn't claim to be an expert in this particular area of security, but I have enough common sense to know that remote attestation is not "critical" for a corporate network. Perhaps it has valuable use cases for very large companies that want complete control over their employee devices, but your claim is far too broad to hold.

It is not just about control, it is also about being able to trust the nodes in your network.

It is not just about employee devices, but about literally every workload or host running in your corporate infrastructure.

Re: Remote Attestation

#55

Post by AnthonyMouse »

Rohansi wrote: post #15
GreenVulpine wrote: post #6

Earlier quoted context omitted.

Make no mistake. Shoving user-hostile malware down people's throats is the primary use case for this in the consumer space. Bootloader malware is very esoteric right now. Enterprise might have valid use cases beyond screwing people but none of them make sense for a consumer device.

> none of them make sense for a consumer device. One of the valid use cases on consumer devices is video game anti-cheat software. Theoretically remote attestation can enable them to be less invasive.

That's the use case it can't really work for.

With enterprise devices you can enroll a specific device and only allow its key. Someone who finds a vulnerability in a different device model, or even the same device model when they don't have one of your actual devices, can't use it because it's not enrolled. (That doesn't actually require remote attestation, the same works without any kind of TPM, but it mitigates a gaping hole that remote attestation has otherwise.)

Because in the video game case the cheater can choose whatever device they want, so they choose one with a vulnerability, which the developers can't prevent without blocking the millions of innocent people who have the same hardware. It's also the solution to yesterday's problem because cheaters are now using cheat hardware that acts as a user input device, and then attesting to what software is running buys you nothing because the cheating is happening in hardware.

Re: Remote Attestation

#56

Post by whiatp »

sfdlkj3jk342a wrote: post #51
solenoid0937 wrote: post #45

Earlier quoted context omitted.

I hope you put a lot more research into those debates than you did with this topic! I just don't understand why you'd have this overconfident hot take about a topic you clearly aren't familiar with. Like, try to understand the article subject and audience first?

I didn't claim to be an expert in this particular area of security, but I have enough common sense to know that remote attestation is not "critical" for a corporate network. Perhaps it has valuable use cases for very large companies that want complete control over their employee devices, but your claim is far too broad to hold.

This article is about using TPMs on servers, not employee devices.

Re: Remote Attestation

#57

Post by toast0 »

solenoid0937 wrote: post #33
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.

It's absolutely useful for corporate owned infrastructure.

But it's also useful for DRM stuff like authorized 4k blu-ray playback on PCs... which is only allowed on systems with Intel SGX.

Re: Remote Attestation

#58

Post by mjmas »

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.

Doing it for company-owned laptops seems a lot different than doing it for customers' devices. I think the complaint is more about the latter.

Re: Remote Attestation

#59

Post by madduci »

The German Healthcare System is moving to the TelematikInfrastruktur 2.0, which has foundations in Zero Trust security, which includes also remote attestation and proof with TPM.

I had made a dummy client as example and I must say that on development perspectives, it is wild.

There are some Go libraries, which support only RSA instead of EC for TPM Keys, on the C++ side you get most of results in Windows through the CryptoProvider, on Linux and Mac exists own OS solutions/access.

Implementing it isn't trivial at all, otherwise you would already seen (not vibe-coded) open source implementions spawning on GitHub.

Re: Remote Attestation

#60

Post by Sayrus »

AnthonyMouse wrote: post #41
gucci-on-fleek wrote: post #22

Earlier quoted context omitted.

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 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 Intel, or find configuration errors in both of their software stacks. Since there have been multiple SGX key extraction vulnerabilities already, all you would have to do is compromise Signal and then use the key extracted from any of…

Since there have been multiple 0-day in kernels, we should drop all security boundaries in them because you'd only need execution on the machine and a known vulnerability.

Since there have been with bypass on service X, we should remove auth because all you need is the vulnerability.

Address space layout randomization wouldn't exist with this mindset, and yet it does and helps for many exploits.

SGX is not fully secure. But neither are the other part of the stack. Security (or trust in this case) is done through layers because it's a question of when you'll be vulnerable, not ifs.

Post reply on HN